From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Relocatable installs |
Date: | 2004-05-18 18:36:19 |
Message-ID: | 40AA57A3.5050608@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>
>> You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
>> environment disables setuid() for security reasons on some platforms. So one
>> would have to wrap every PG related program into equally named shell scripts or
>> aliases to just set it for the program call alone.
>
> Why would any pg tools need to be setuid?
That's got nothing to do with what I said. Setting LD_LIBRARY_PATH will
possibly affect everything else that needs setuid.
>
> But it's just wrong to have a binary that doesn't run unless you have
> environment variables set up.
>
>> Relocatable installation means static linking of our tools against our own
>> libs. This does not mean static linking entirely, but at least static linking
>> against libpq.a.
>
> The normal approach is to use rpath for relocatable installs.
> That's what it's there for.
> Static linking would work too but it's overkill.
I don't mean complete static linking. But what's wrong with linking psql
and other PostgreSQL utilities against libpq.a instead of libpq.so?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql | 2004-05-18 18:49:00 | Re: Table Spaces |
Previous Message | Neil Conway | 2004-05-18 17:53:03 | Re: bitwise and/or aggregate functions? |