Re: problems with startup script on upgrade
От | Alexander Klimov |
---|---|
Тема | Re: problems with startup script on upgrade |
Дата | |
Msg-id | Pine.SUN.4.21.0103181831310.15299-100000@dardar.wisdom.weizmann.ac.il обсуждение исходный текст |
Ответ на | Re: problems with startup script on upgrade ("Martin A. Marques" <martin@math.unl.edu.ar>) |
Ответы |
Re: Re: problems with startup script on upgrade
|
Список | 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 по дате отправления: