On Thu, 3 Aug 2006, Matthew Miller wrote:
On Wed, Aug 02, 2006 at 11:48:49PM -0400, David Scriven wrote:
One can set LD_LIBRARY_PATH manually - ie. from the prompt
and things work fine.
My guess that somewhere it is being UNSET, but I can't figure
out where. This happens on different machines running either
FC4 or FC5.
Something must be "sanitizing" it for security reasons. Interesting.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164869
I recall running into this sometime around RH9. I thought I had filed a
bug, but I can't find it now. I did find this, though:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118262
And I wonder if the conclusion is relevant:
Comment #3 From Jason Vas Dias:
This bug is blocked by glibc bug 129682 - no setuid/setgid program
can obtain LD_LIBRARY_PATH from the environment of a non-owner
invoking user.
at could be converted to not require setuid/setgid bits to be set -
will work on this for next at version.
Comment #4 From Jason Vas Dias:
It seems the glibc developers consider this not a bug,
but a security feature that is unlikely to be changed.
So you'll just have to set LD_LIBRARY_PATH manually
in your at jobs - it won't be recorded from your
invoking environment if you are not root.
For the reader's convenience:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129682
The question is, when logging in via the display manager, does something
setuid/setgid get run after .bash_profile? Then, is there some startup
script that gets run after that program that could set the environment?
In my experience, logging in not via the display manager results in
LD_LIBRARY_PATH being set from .bash_profile as expected.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
