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:
	VARIABLE_NAME=VARIABLE_VALUE

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:
	iccvars.sh
	iccvars.csh

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


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
	fi
	$ 

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
LD_LIBRARY_PATH.

Just to add that this also happens with kde based desktop-setups

Mailing list comments indicate that this is still happening in FC5.

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.

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.

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.

Is this explanation of this bug http://kbase.redhat.com/faq/FAQ_43_9302 ? I.e.,
is just (mis-?)feature?

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...?

"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.

The ssh_agent is setgid to avoid ptrace attacks on it to obtain the private keys
of the user.

hey ! the kbase in question is a workaround. i had written that courtesy of
ssh-agent.

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.

i *personall* add LD_LIBRARY_PATH as mentioned below

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

this shoud workaround LD_LIBRARY_PATH being set twice.

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.

can someone mark this for rawhide, rather than fc5 ?

(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.

Per comment 17 switching this bug to Fedora/devel (I agree, it really shifted to
-devel area).

To help Google find this ticket, here's an xref to a related issue in Debian:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257730

*** Bug 228019 has been marked as a duplicate of this bug. ***

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.

Using a script in /etc/profile.d to export LD_LIBRARY_PATH and other variables
works well.

Heya Robert, would it be possible for you to provide the script ?

#!/bin/sh
export DIALOGBLOCKSDIR=/home/rfinlon/DialogBlocks-3.14
export PATH=$PATH:$DIALOGBLOCKSDIR
export PGDATA=/usr/local/pgsql/data
export PGLIB=/usr/local/pgsql/lib
export PGDATESTYLE="US,SQL"
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.

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"

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.

Heya Robert, would you try executing the stated command ( comment#26) from run
dialog box ( Alt+F2 ) and confirm the results ?

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.

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 on attachment 144136 [details]
proposed patch

this patch seems to be borked.

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.

We should probably just change ssh-agent to use its alternate syntax instead of
doing the pass through way we do now.

I'm wondering why we can't just simply replace these lines in XSession

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

with

   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?

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?

Sounds reasonable to me; does it work ?

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:

#!/bin/sh
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\""; \
)

Soren, should we do this easy fix ?

I am fine with this fix if it works.

Works fine for me, I'll attach an Xsession that has this change for all cases of
SSH_LAUNCH

ah, there's a patch already

comment #36 works good.

These fixes are thwarted by the console applications (xterm & Konsole at 
least) being install setgid utempter.

I have created Bug 243069.

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.

Personal note:

rhel4 bug is marked against bugzilla#208148.
i would suggest that a service request be opened to track this issue .

Ok will try that 

Built xorg-x11-xinit-1_0_2-23_fc8, which should show up in rawhide.

(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 ?

> 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.

This bug still exists in fedora 19.

This bug seems to be present also in CentOS Linux release 7.3.1611 (Core).

Is it possible?