ssh-agent clobbers LD_LIBRARY_PATH and other environment variables

Argh!

Well, this explains why my .profile setting of LD_LIBRARY_PATH doesn't actually survive into my login.

This still happens in Feisty (or else something else is clobbering LD_LIBRARY_PATH). If the work-around above doesn't work, I'll post another comment shortly.

Tried the work around script, and I can see from ps that it is 'working' (my LD_LIBRARY_PATH shows up in the command line as it should), but something is still unsetting the variable. I have set the variable in both .bash_profile, and a script in .kde/env/, and in neither my desktop session nor a terminal session is the variable set (I'm using kubuntu/KDE, as you can guess).

I also managed to find this on my own, but I have to wonder; why is ssh-agent sgid? Searching the entire filesystem after files belonging to the "ssh" group yields no results, so I don't see what benefits ssh-agent would gain from being sgid.

Isn't the obvious solution to just remove sgid privileges from ssh-agent?

I seem to be having the same problem with _my_ lifestyle... :-(

I'd given up on per-user env vars for awhile, but I'm now installing a new computer so I'm having another go.

I tested ~/.pam_environment:
PAT OVERRIDE=${PATH}
PATH OVERRIDE=/home/alan/bin:${PATH}

and this happens [on console login]:

alan@singularity:~$ set|grep ^PAT
PAT=/home/alan/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games

so it seems PATH gets set to what I told it to, PAT gets set based on that value (despite being earlier in ~/.pam_environment), then something else unsets it. And it's not just ssh-agent doing it, because it happens even if I remove the openssh-client package.

Have you discovered what unsets the LD_LIBRARY_PATH?
Something apparently overrides the value I give it in /etc/profile, but what?

LD_LIBRARY_PATH is unset automatically for set-group-id binaries.

ssh-agent is setgid ssh to prevent ptrace attacks (i.e. if it were not setgid, an attacker who had managed to compromise your account could also bypass passphrase protection on your key by ptracing a running ssh-agent). I'm afraid I have no intention of disabling this protection.

I think our long-term plan for this is to have Upstart manage ssh-agent for user sessions so that ssh-agent no longer needs to be a parent of the other session processes. This is still some way off, though.

Same bug for me. I may define LD_LIBRARY_PATH from .bashrc or .zshrc, it will be OK, but only from a console, and won't be if I run an application from a *.desktop file as an example. So I wanted to define it in .profile, but what ever I do, it seems to be cleared unconditionally after interpretation of .profile. There is ldconfig, but unfortunately, this acts system wide, and I won't add a system wide entry for a library path which is relevant only for a single user.

This bug should be solved, and it seems it is still not solved.

For people seeking for a workaround, there is one in message #21 of this other similar bug report:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/366728

This bug is still there in the latest (X)ubuntu 12.04 (development) daily ISO.

Can someone change in /etc/X11/Xsession.options the line:

use-ssh-agent

to

no-use-ssh-agent

?

This is the workaround referenced above and it seems to work well.

This works for me: on Ubuntu 11.10

echo STARTUP=\"/usr/bin/env LD_LIBRARY_PATH=\${LD_LIBRARY_PATH} \${STARTUP}\" | sudo tee /etc/X11/Xsession.d/90preserve_ld_library_path

I forgot to say the source of this: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/366728/comments/17

This bug is still present the latest Ubuntu 18.04.