Bug 164869 - LD_LIBRARY_PATH not inherited from .bash_profile
Summary: LD_LIBRARY_PATH not inherited from .bash_profile
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
: 228019 (view as bug list)
Depends On:
Blocks: FC7Target FC4Update 208148
TreeView+ depends on / blocked
Reported: 2005-08-02 02:32 UTC by Martin
Modified: 2018-04-11 15:56 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-29 23:33:42 UTC
Type: ---

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

Description Martin 2005-08-02 02:32:49 UTC
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-03 00:27:39 UTC
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 12:12:42 UTC
Just to add that this also happens with kde based desktop-setups

Comment 3 Matthew Miller 2006-08-03 14:22:55 UTC
Mailing list comments indicate that this is still happening in FC5.

Comment 4 Thomas Okken 2006-08-19 11:06:18 UTC
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 11:39:43 UTC
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 21:24:10 UTC
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 12:15:49 UTC
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 13:07:18 UTC
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 16:34:22 UTC
"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 11:33:16 UTC
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 14:58:13 UTC
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 21:43:54 UTC
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 19:55:41 UTC
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 20:01:31 UTC
can someone mark this for rawhide, rather than fc5 ?

Comment 18 aaron scamehorn 2006-12-20 21:33:37 UTC
(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 23:14:51 UTC
Per comment 17 switching this bug to Fedora/devel (I agree, it really shifted to
-devel area).

Comment 20 Vadim Nasardinov 2006-12-27 14:39:23 UTC
To help Google find this ticket, here's an xref to a related issue in Debian:


Comment 21 Matěj Cepl 2007-02-14 09:04:58 UTC
*** Bug 228019 has been marked as a duplicate of this bug. ***

Comment 22 Robert Finlon 2007-02-14 17:21:51 UTC
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 17:24:30 UTC
Using a script in /etc/profile.d to export LD_LIBRARY_PATH and other variables
works well.

Comment 24 ritz 2007-02-15 15:33:46 UTC
Heya Robert, would it be possible for you to provide the script ?

Comment 25 Robert Finlon 2007-02-15 18:32:03 UTC
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 19:48:08 UTC
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 20:30:41 UTC
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 20:33:54 UTC
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 21:18:48 UTC
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 21:34:15 UTC
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 14:26:03 UTC
Comment on attachment 144136 [details]
proposed patch

this patch seems to be borked.

Comment 32 ritz 2007-02-20 14:49:59 UTC
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 23:08:50 UTC
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 10:19:57 UTC
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 10:48:51 UTC
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 14:07:25 UTC
Sounds reasonable to me; does it work ?

Comment 38 Stefan Becker 2007-04-11 15:26:22 UTC
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 23:08:40 UTC
Soren, should we do this easy fix ?

Comment 40 Søren Sandmann Pedersen 2007-04-20 14:45:01 UTC
I am fine with this fix if it works.

Comment 41 Matthias Clasen 2007-04-20 18:08:19 UTC
Works fine for me, I'll attach an Xsession that has this change for all cases of

Comment 42 Matthias Clasen 2007-04-20 18:11:15 UTC
ah, there's a patch already

Comment 43 ritz 2007-05-23 10:49:54 UTC
comment #36 works good.

Comment 44 Peter TB Brett 2007-06-07 06:58:54 UTC
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 21:17:13 UTC
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 05:47:13 UTC
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 19:03:24 UTC
Ok will try that 

Comment 48 Søren Sandmann Pedersen 2007-07-29 23:33:42 UTC
Built xorg-x11-xinit-1_0_2-23_fc8, which should show up in rawhide.

Comment 49 Sev Binello 2007-07-30 14:11:38 UTC
(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 21:18:49 UTC
> 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 15:25:36 UTC
This bug still exists in fedora 19.

Comment 52 Ruben Di Battista 2017-09-08 09:44:55 UTC
This bug seems to be present also in CentOS Linux release 7.3.1611 (Core).

Is it possible?

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