Re: problems with startup script on upgrade - Mailing list pgsql-hackers

From Alexander Klimov
Subject Re: problems with startup script on upgrade
Date
Msg-id Pine.SUN.4.21.0103181831310.15299-100000@dardar.wisdom.weizmann.ac.il
Whole thread Raw
In response to Re: problems with startup script on upgrade  ("Martin A. Marques" <martin@math.unl.edu.ar>)
Responses Re: Re: problems with startup script on upgrade  (Peter Eisentraut <peter_e@gmx.net>)
List 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
tothe 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
userand    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
directoriesspeci-    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/libthe clean -- avoid using
LD_LIBRARY_PATH,use -R for linking instead
 

Regards,
ASK



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Urgent Question on Postgresql
Next
From: Tom Lane
Date:
Subject: pg_ctl problem (was Re: BeOS Patch)