Thanks go to:
Joe Mario <mario_at_zk3.dec.com>
Serguei Patchkovskii <patchkov_at_ucalgary.ca>
John.McNulty_at_ntl.com
Daniel S. Riley <dsr_at_mail.lns.cornell.edu>
Bob Vickers <bobv_at_dcs.rhbnc.ac.uk>
Joerg Bruehe <joerg_at_sql.de>
Alex Nord <Alex_Nord_at_Jabil.com>
Joe Fletcher <joe_at_meng.ucl.ac.uk>
It looks like that for (obvious) security reasons the OS munges
LD_LIBRARY_PATH (and _RLD_LIST, _RLD_ARGS, _RLD_ROOT) when a suid program
is executed. Usually this variable is simply cleaned, but because in my
case the 'su' command is executed from from a setuid program like
xterm, things are a little bit complicated.
Here are Joe Mario's answers:
Answer #1
I work on the Tru64 UNIX loader. Here is some explanation about
what is happening. The loader, for security reasons, must
track _RLD_LIST, _RLD_ARGS, _RLD_ROOT, and LD_LIBRARY_PATH.
When the loader sees any process transition from one effective
uid to another effective uid (as with suid programs), it always
ignores the above four environment variables.
However, for programs like xterm, which are suid programs, but
result in a new process with the same effective uid as the caller,
the loader must track and mark the original values of the the above
four variables so that it can properly restore them when the xterm
results in a new process which is the same as the caller.
I'm puzzled in your mail when you say you're seeing the
variables not properly cleaned up after an su, and only on
certain releases. I can't reproduce that here.
Answer #2:
When something like xterm is being executed, the uid/gid change
from the user, to root, and then back to the original user.
The LD_LIBRARY_PATH marking that is done is to append the original
user's gid/uid so that the loader can properly restore the
LD_LIBRARY_PATH when the xterm creates the users' process.
You'll notice that the mangling is just the appending of the gid/uid.
My original question:
> Hello Tru64 managers,
>
> I found a weird problem with 'su', that is it looks like it's trashing
> some environment variables.
>
> The 'man su' says:
> Except in a case where the - option is used, the user environment is
> unchanged except for HOME, SHELL, USER, and LOGNAME which are taken from
> the password file for the user being substituted (see environ).
>
> Notably, this happens to me with LD_LIBRARY_PATH.
>
> Please read here:
>
> mgais % LD_LIBRARY_PATH=/usr/lib:/usr/lib/X11:/usr/shlib
> mgais % export LD_LIBRARY_PATH
> mgais % echo $LD_LIBRARY_PATH
> /usr/lib:/usr/lib/X11:/usr/shlib
>
> and now...
>
> mgais % su
> Password:
> # echo $LD_LIBRARY_PATH
> ÿ53ÿ141ÿ/usr/lib:/usr/lib/X11:/usr/shlib
>
> With 'od' I could see that those weird chars are:
> 0xff _userUID_ 0xff _userGID_ 0xff
>
> The problem is the same if I start with sh/bash/csh user shell
> Root shell is sh
>
> The problem seems to affect only for DU v4.0d/v4.0f machines,
> not for Tru64 v5.0
>
> If I type 'su otheruser', (with a sh/bash user) the
> LD_LIBRARY_PATH will be unset
>
> Of course, if I type 'su -', the variable is re-initialized correctly.
>
> Could you please check if on your machine there is such a problem,
> or if it should be something related to my login scripts ?
>
Massimo Gais <mgais_at_na.astro.it>
----
"UNIX is user friendly. It's just selective
about who its friends are..."
Received on Mon Apr 17 2000 - 13:36:21 NZST