LD_LIBRARY_PATH set in ~/.profile doesn't stick

[Peter Clifton]

Binary package hint: gdm

/etg/gdm/Xsession sources ~/.profile, which I've been relying on to allow locally built and installed applications to run from the GNOME menus and GUI environemnt.

the PATH environment variable is being set and preserved correctly, however as of updates today (9th Jan 2008), the LD_LIBRARY_PATH is not being retained through to the desktop session.

I'm not entirely sure if gdm is to blame for this or not, but it seemed a likely place to start looking.

[Sebastien Bacher (seb128)]

thank you for your bug report, do you mean 2009 rather than 2008? what ubuntu version do you use? what did you upgrade?

[Peter Clifton (pcjc2)]

Sorry, I did indeed mean 2009.. time does fly!

This is with Jaunty, and I think the effect I'm seeing is a known "feature" of ssh-agent being set GID. glibc will strip certain sensitive environment variables.

The funny thing is.. this was working for a while, but I can't figure out what changed. Either the env-var stripping wasn't working, or my system wasn't running the desktop as a sub-process of ssh-agent.

For now, I've worked around my issue by adding my local gEDA testing install folder to /etc/ld.so.conf.d, although that wouldn't work well if I wasn't "root" as well as pcjc2.

As an alternative.. would it be possible to run ~/.profile from a subprocess of ssh-agent as well? (Or to re-set the LD_LIBRARY_PATH on the sub-process run by ssh-agent?)

[Sebastien Bacher (seb128)]

do you still get the issue in current jaunty?

[timconinx (tim-coninx)]

I can acknowledge this bug.

Upgraded from Intrepid, running latest Jaunty (updates this morning).
LD_LIBRARY_PATH is set in .gnomerc, but after login it doesn't show up with an echo.

Collegues of mine which reinstalled a fresh Jaunty experience the same problem, and also resolved it by accessing ld.so.conf

[Sebastien Bacher (seb128)]

do you get the issue if you don't use gdm to start your session?

[Sebastien Bacher (seb128)]

could also be interesting to start a not GNOME session to see if that's an issue there

[timconinx (tim-coninx)]

I did a quick check doing a GNOME session from kdm: the issue is there.

Personally, I'm using .gnomerc. I'm setting two variables, LD_LIBRARY_PATH and LDLIBRARYPATH, and from gdm as well as kdm the first variable is lost (no output on echo) while the second one is still there

[Max Bowsher (maxb)]

It would appear that this is a known issue in that it is documented in /usr/share/doc/openssh-client/README.Debian.gz.

I think we can declare this not a bug in GDM, but somewhere hovering between openssh and x11-common (since x11-common installs the Xsession.d script which folds ssh-agent into the session startup).

This is a rather thorny problem, since there are so many conflicting requirements:
 * be setgid to afford ssh-agent protection from ptrace()
 * retain behaviour of ssh-agent exiting when the X session does
 * allow ssh-agent to insert envvars into the X session environment
 * don't be put a setgid process on the chain of execs launching the X session (to avoid this bug)

I don't see any way out which doesn't involve writing a non-trivial wrapper which launches the setgid ssh-agent in a mode which emits the envvars to stdout, incorporates the envvars into its own environment, forks the rest of the X session, and then waits for the X session to exit at which point it kills the ssh-agent.

Quite the can of worms.

[Loïc Minier (lool)]

Striping of some env vars such as LD_LIBRARY_PATH, LD_PRELOAD, or HOSTALIASES will happen automatically when calling a suid/sgid binary. I had this issue with xterm recently (sgid utmp) and I see that ssh-agent is mentionned here (sgid ssh).

I don't know if it can easily be implemented in ssh-agent, but vte uses a helper for sgid tasks (/usr/lib/libvte9/gnome-pty-helper) which allows programs such as gnome-terminal to not be sgid.

[Nick Holloway (nwholloway)]

As a workaround, I just comment out "use-ssh-agent" in /etc/X11/Xsession.options.

As I use Xubuntu, the XFCE startup launches "ssh-agent" anyway, I am still able to use "ssh-add" with no loss of functionality.

[Loïc Minier (lool)]

So the setgid bit which causes this effect is actually on purpose; from README.Debian:

Setgid ssh-agent and environment variables
------------------------------------------

As of version 1:3.5p1-1, ssh-agent is installed setgid to prevent ptrace()
attacks retrieving private key material. This has the side-effect of causing
glibc to remove certain environment variables which might have security
implications for set-id programs, including LD_PRELOAD, LD_LIBRARY_PATH, and
TMPDIR.

If you need to set any of these environment variables, you will need to do
so in the program exec()ed by ssh-agent. This may involve creating a small
wrapper script.