Bug 164869 - LD_LIBRARY_PATH not inherited from .bash_profile
LD_LIBRARY_PATH not inherited from .bash_profile
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
: 228019 (view as bug list)
Depends On:
Blocks: FC7Target FC4Update 208148
  Show dependency treegraph
Reported: 2005-08-01 22:32 EDT by Martin
Modified: 2014-06-18 05:07 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-29 19:33:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (3.40 KB, text/x-patch)
2006-12-20 14:55 EST, ritz
no flags Details
proposed patch to fix LD_LIBRARY_PATH issue. (3.39 KB, patch)
2007-02-20 09:49 EST, ritz
no flags Details | Diff

  None (edit)
Description Martin 2005-08-01 22:32:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
gdm (or something) is resetting LD_LIBRARY_PATH so non-login terminal sessions don't pick it up.

Didn't notice this before FC4, but maybe it's always been this way?  Is it a bug or a feature??

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  export RANDOM_STUFF="xxx" ; export LD_LIBRARY_PATH="mylibs" in .bash_profile
2.  Log in through gdm
3.  gnome-terminal: env command shows RANDOM_STUFF but not LD_LIBRARY_PATH

Expected Results:  All symbols set in .bash_profile at login time should be inherited by a non-login terminal.

Additional info:

This is an FC4 system recently upgraded from FC3.

Noticed this because I want to make application launchers on my Gnome panels that invoke applications that use my private libraries.  Yes, I can work around with extra scripts. :-(
Comment 1 Dimitri Papadopoulos 2005-11-02 19:27:39 EST
As a workaround, try setting LD_LIBRARY_PATH in /etc/environment. Note that *no
shell* is executed to parse this file, it just contains lines such as:

The above is only a workaround. I just noticed the problem as well and the above
workaround doesn't work for me: my problem has to do with the Intel C++ compiler
and Intel provide two scripts to set the required environment variables:

Here is what these scripts do (partly):
	$ . /opt/intel/cc/9.0/bin/iccvars.sh

The canonical way of using such scripts is adding them to .bash_profile:
	$ tail -8 ~/.bash_profile
	# User specific environment and startup programs
	# Intel C++
	if [ -f /opt/intel/cc/9.0/bin/iccvars.sh ]; then
		. /opt/intel/cc/9.0/bin/iccvars.sh

This works with text logins, but LD_LIBRARY_PATH is reset during graphical
logins. Programs built with the Intel C++ compiler fail for lack of a proper
Comment 2 Martin Knoblauch 2006-01-20 07:12:42 EST
Just to add that this also happens with kde based desktop-setups
Comment 3 Matthew Miller 2006-08-03 10:22:55 EDT
Mailing list comments indicate that this is still happening in FC5.
Comment 4 Thomas Okken 2006-08-19 07:06:18 EDT
I, too, noticed that LD_LIBRARY_PATH somehow disappears from the environment in
graphical logins. Console (text) logins are fine.
This happened after I recently upgraded from FC3 to FC5; it causes problems
using the Oracle OCI driver from Java.

The culprit is ssh-agent, which is used by the /etc/X11/xinit/Xsession script to
launch the session manager. The ssh-agent executable is has its setgid bit set;
this causes the kernel to remove LD_LIBRARY_PATH from the environment before
launching it. (LD_LIBRARY_PATH must be removed from the environment for setuid
and setgid executables; not doing so would open a huge security hole.)

I don't know enough about ssh-agent to be able to say whether it actually needs
to be "setgid nobody" or not; if not, the easy fix is to remove the setgid bit,
and otherwise, the Xsession script should be modified so that it does not run
the session manager as a descendant of the ssh-agent process, but instead uses
ssh-agent's "-s" option to generate the appropriate startup commands and run
them separately.
Alternatively, Xsession could generate a wrapper script on the fly, which
contains an "export LD_LIBRARY_PATH=" command, and wraps around the dbus-launch
command, to restore LD_LIBRARY_PATH to the environment before invoking the
session manager.
Comment 5 Thomas Okken 2006-08-20 07:39:43 EDT
Just a thought, due also to bug 118262 -- you could argue that the real problem
is the fact that LD_LIBRARY_PATH is *removed* from the environment, while
keeping dynamic linking secure only requires that ld.so *ignore* it for
setuid/setgid executables.
That way, such executables could still pass LD_LIBRARY_PATH on to their
descendants, without requiring ugly workarounds.
Comment 6 Matěj Cepl 2006-10-17 17:24:10 EDT
Also Bug 208148 (which is dup for RHEL 4.4). I was able to reproduce this on
FC5. We are working on resolving this issue.
Comment 7 Matěj Cepl 2006-11-20 07:15:49 EST
Is this explanation of this bug http://kbase.redhat.com/faq/FAQ_43_9302 ? I.e.,
is just (mis-?)feature?
Comment 8 Martin 2006-11-20 08:07:18 EST
I regard this KB info as a workaround.  (Interesting, though.)  All the rest of
the environment is available in a non-login shell -- why not LD_LIBRARY_PATH? It
is unexpected behavior for a general user and can cause a lot of lost time due
to head-scratching.

So the classic question: Is it a bug or a feature?  If there is an alternate way
to get needed security without great effort, then it's a bug to be fixed...?
Comment 9 Thomas Okken 2006-11-20 11:34:22 EST
"The classic question: Is it a bug or a feature?" You're kidding, right?
LD_LIBRARY_PATH gets removed from the environment as a side effect of how
seduid/setgid executables work. In older versions of Fedora and Red Hat, this
did *not* happen, because the sequence of bringing up a graphical login did not
include any setuid/setgid executables (or if it did, at least they were not the
ones that ended up spawning the session manager). Please see comment #4.

The KB information mentioned in comment #7 has the undesirable side effect of
running your .bash_profile twice. That's a pretty ugly way of restoring
LD_LIBRARY_PATH, and besides, it doesn't do anything for programs that you start
from one of the window manager's menus rather than from a terminal.
Comment 10 Tomas Mraz 2006-11-24 06:33:16 EST
The ssh_agent is setgid to avoid ptrace attacks on it to obtain the private keys
of the user.

Comment 12 ritz 2006-11-25 09:58:13 EST
hey ! the kbase in question is a workaround. i had written that courtesy of

i have attahched a patch to IT associated with bug#208148. bash_profile is still
not being checked up. as yet, only workaround i found is to migrate to ~/.bashrc . 

checking this up further.
Comment 14 ritz 2006-11-29 16:43:54 EST
i *personall* add LD_LIBRARY_PATH as mentioned below

if ! echo "$LD_LIBRARY_PATH" | grep -q /my/path ; then

this shoud workaround LD_LIBRARY_PATH being set twice.

Comment 15 ritz 2006-12-20 14:55:41 EST
Created attachment 144136 [details]
proposed patch

A wrapper script to start desktop session and saving LD_LIBRARY_PATH .
To apply the patch

cd /
cat xinitrc_ld_library_path.patch| patch -p0
chmod a+x /etc/X11/xinit/xinitrc-ssh

log-out and login. This should resolve the issue.
Comment 17 ritz 2006-12-20 15:01:31 EST
can someone mark this for rawhide, rather than fc5 ?
Comment 18 aaron scamehorn 2006-12-20 16:33:37 EST
(In reply to comment #15)

> A wrapper script to start desktop session and saving LD_LIBRARY_PATH .
> To apply the patch

Confirmed.  Works for me.  RHEL4.4.
Comment 19 Matěj Cepl 2006-12-20 18:14:51 EST
Per comment 17 switching this bug to Fedora/devel (I agree, it really shifted to
-devel area).
Comment 20 Vadim Nasardinov 2006-12-27 09:39:23 EST
To help Google find this ticket, here's an xref to a related issue in Debian:

Comment 21 Matěj Cepl 2007-02-14 04:04:58 EST
*** Bug 228019 has been marked as a duplicate of this bug. ***
Comment 22 Robert Finlon 2007-02-14 12:21:51 EST
Using a script in /etc/profile.d to export LD_LIBRAY_PATH works fine for what I
am doing. This should work for nearly all users.
Comment 23 Robert Finlon 2007-02-14 12:24:30 EST
Using a script in /etc/profile.d to export LD_LIBRARY_PATH and other variables
works well.
Comment 24 ritz 2007-02-15 10:33:46 EST
Heya Robert, would it be possible for you to provide the script ?
Comment 25 Robert Finlon 2007-02-15 13:32:03 EST
export DIALOGBLOCKSDIR=/home/rfinlon/DialogBlocks-3.14
export PGDATA=/usr/local/pgsql/data
export PGLIB=/usr/local/pgsql/lib
export SERVER=/usr/local/pgsql/bin/postmaster
export LD_LIBRARY_PATH=/usr/local/pgsql/lib:/usr/lib/mono:/usr/local/pgsql/include
export PGCTL=/usr/local/pgsql/bin/pg_ctl
export LOGFILE=/usr/local/pgsql/data/postmaster.log

Note that I export almost everything from /etc/profile.d that is custom for
Postgres as well as the LD_LIBRAY_PATH variable.

Comment 26 ritz 2007-02-15 14:48:08 EST
Heya Robert,

  if i understand correctly, you are using gnome-terminal to see the
LD_LIBRARY_PATH or from console session ?

  On my test system ( rawhide ) using run dialog ( Alt+F2 ) on gnome still does
not print LD_LIBRARY_PATH with the command below, when ssh-agent invokes the
desktop session as expected.

  zenity --info --text "path : $LD_LIBRARY_PATH"
Comment 27 Robert Finlon 2007-02-15 15:30:41 EST
I login with a graphical login. I do a lot with command line entries so I start
a gnome terminal while in a graphical environment. All variables from
/etc/profile were available except LD_LIBRARY_PATH. I was able to correct the
problem by creating a script in /etc/profile.d and it works fine.
I suggest not editing /etc/profile after instaallation but use simple scripts in
/etc/profile.d to export the variables that your applications need.
Comment 28 ritz 2007-02-15 15:33:54 EST
Heya Robert, would you try executing the stated command ( comment#26) from run
dialog box ( Alt+F2 ) and confirm the results ?
Comment 29 Robert Finlon 2007-02-15 16:18:48 EST
Sorry! No results were returned from using Alt+F2 on my system.
The comment on this report states LD_LIBRARY_PATH not inherited from
.bash_profile. I originally submitted as issue with /etc/profile exports.
Neither worked for LD_LIBRARY_PATH so I followed a tip to use /etc/profile.d and
now all is well.
Comment 30 ritz 2007-02-15 16:34:15 EST
thanks for confirming Robert. the bug effects LD_LIBRARY_PATH for a desktop
session stated by ssh-agent , irrespective of where the stated variable is set (
profile, bashrc, ... ) .
Comment 31 ritz 2007-02-20 09:26:03 EST
Comment on attachment 144136 [details]
proposed patch

this patch seems to be borked.
Comment 32 ritz 2007-02-20 09:49:59 EST
Created attachment 148413 [details]
proposed patch to fix LD_LIBRARY_PATH issue.

A wrapper script to start desktop session and saving LD_LIBRARY_PATH .
To apply the patch

cd /
touch etc/X11/xinit/xinitrc-ssh
cat /path/to/xinitrc_ld_library_path.patch| patch -p0
chmod a+x /etc/X11/xinit/xinitrc-ssh

log-out and login. This should resolve the issue.
Comment 33 Ray Strode [halfline] 2007-02-27 18:08:50 EST
We should probably just change ssh-agent to use its alternate syntax instead of
doing the pass through way we do now.
Comment 35 Stefan Becker 2007-04-11 06:19:57 EDT
I'm wondering why we can't just simply replace these lines in XSession

   exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"


   exec $SSH_AGENT $SHELL -l -c "$DBUS_LAUNCH gnome-session"

i.e. instead of wrapping the ssh-agent call in a login shell we create the login
shell (that sets LD_LIBRARY_PATH etc.) from ssh-agent?
Comment 36 Stefan Becker 2007-04-11 06:48:51 EDT
One more refinement as tcsh only supports -l as sole option:

  exec $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"$DBUS_LAUNCH gnome-session\""

How does that sound?
Comment 37 Matthias Clasen 2007-04-11 10:07:25 EDT
Sounds reasonable to me; does it work ?
Comment 38 Stefan Becker 2007-04-11 11:26:22 EDT
Well at least LD_LIBRARY_PATH is OK with it. Here is a little hack script I used
for testing. You of course need to add LD_LIBRARY_PATH to
.profile/.bash_profile/.login to see the effect:

echo Original shell
env | fgrep -e SSH -e LD_LIBRARY_PATH
( \
    echo "Shell 1"; \
    exec -l /bin/sh -c "/usr/bin/ssh-agent env" | fgrep -e SSH -e LD_LIBRARY_PATH; \
( \
    echo "Shell 2"; \
    exec /usr/bin/ssh-agent /bin/sh -l -c "env | fgrep -e SSH -e LD_LIBRARY_PATH"; \
( \
    echo "Shell 3"; \
    exec /usr/bin/ssh-agent /bin/sh -l -c "env | fgrep -e SSH -e LD_LIBRARY_PATH"; \
( \
    echo "Shell 4"; \
    exec /usr/bin/ssh-agent /bin/sh -c "ps -efw | fgrep ssh-agent; ps; exec -l
/bin/tcsh -c \"env | fgrep -e SSH -e LD_LIBRARY_PATH\""; \
Comment 39 Matthias Clasen 2007-04-17 19:08:40 EDT
Soren, should we do this easy fix ?
Comment 40 Søren Sandmann Pedersen 2007-04-20 10:45:01 EDT
I am fine with this fix if it works.
Comment 41 Matthias Clasen 2007-04-20 14:08:19 EDT
Works fine for me, I'll attach an Xsession that has this change for all cases of
Comment 42 Matthias Clasen 2007-04-20 14:11:15 EDT
ah, there's a patch already
Comment 43 ritz 2007-05-23 06:49:54 EDT
comment #36 works good.
Comment 44 Peter TB Brett 2007-06-07 02:58:54 EDT
These fixes are thwarted by the console applications (xterm & Konsole at 
least) being install setgid utempter.

I have created Bug 243069.
Comment 45 Sev Binello 2007-06-19 17:17:13 EDT
I see this bug listed several places here.
Is there a bona fide fix for this problem ?
We just upgraded to WS4 U5 and still see the same problem.
Comment 46 ritz 2007-06-20 01:47:13 EDT
Personal note:

rhel4 bug is marked against bugzilla#208148.
i would suggest that a service request be opened to track this issue .
Comment 47 Sev Binello 2007-06-21 15:03:24 EDT
Ok will try that 
Comment 48 Søren Sandmann Pedersen 2007-07-29 19:33:42 EDT
Built xorg-x11-xinit-1_0_2-23_fc8, which should show up in rawhide.
Comment 49 Sev Binello 2007-07-30 10:11:38 EDT
(In reply to comment #48)
> Built xorg-x11-xinit-1_0_2-23_fc8, which should show up in rawhide.
How should one interpret this message ?
Comment 50 Søren Sandmann Pedersen 2007-08-01 17:18:49 EDT
> How should one interpret this message ?

It means a new version (1.0.2-23.fc8) should appear in the latest development
version of Fedora. I believe the bug should be fixed there.
Comment 51 David Jones 2013-09-06 11:25:36 EDT
This bug still exists in fedora 19.

Note You need to log in before you can comment on or make changes to this bug.