Re: problems with startup script on upgrade

From: Alexander Klimov <ask(at)wisdom(dot)weizmann(dot)ac(dot)il>
To: "Martin A(dot) Marques" <martin(at)math(dot)unl(dot)edu(dot)ar>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: problems with startup script on upgrade
Date: 2001-03-18 16:40:32
Message-ID: Pine.SUN.4.21.0103181831310.15299-100000@dardar.wisdom.weizmann.ac.il
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all

On Fri, 16 Mar 2001, Martin A. Marques wrote:
> ld.so.1: /dbs/postgres/bin/postmaster: fatal: libz.so: open failed: No such
> file or directory
>
> Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it
> that Solaris doesn't load the .profile in the postgres directory.

The main trouble with all of this is that LD_LIBRARY_PATH is irrelevant
here.

From man ld.so.1:

SECURITY
To prevent malicious dependency substitution or symbol
interposition, some restrictions may apply to the evaluation
of the dependencies of secure processes.

The runtime linker categorizes a process as secure if the
user is not a super user, and either the real user and
effective user identifiers are not equal, or the real group
and effective group identifiers are not equal. See
getuid(2), geteuid(2), getgid(2), and getegid(2).

If an LD_LIBRARY_PATH environment variable is in effect for
a secure process, then only the trusted directories speci-
fied by this variable will be used to augment the runtime
linker's search rules. Presently, the only trusted direc-
tory known to the runtime linker is /usr/lib.

There are many way to solve the problem:
the easy -- copy (or link) libz.so to /usr/lib
the clean -- avoid using LD_LIBRARY_PATH, use -R for linking instead

Regards,
ASK

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-18 17:11:54 pg_ctl problem (was Re: BeOS Patch)
Previous Message Tatsuo Ishii 2001-03-18 14:10:27 Re: Urgent Question on Postgresql