Bug 135705 – sys-apps/shadow - su --preserve-environment resets PATH

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Paul Forgey 2006-06-05 19:08:22 UTC]

There doesn't seem to be a way to su a process from root to another user preserving all of the environment and the PATH variable.

When su is used with no options, the path environment is set as expected from login.defs.  When used with --preserve-environment (or -m), PATH gets set to "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin".

For example:
rover freenet # export PATH=/modified:$PATH
rover freenet # echo $PATH
/modified:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/jre1.5.0_07/bin:/usr/qt/3/bin
rover freenet # su freenet -c "echo \$PATH"
/bin:/usr/bin
rover freenet # su -m freenet -c "echo \$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[Comment 1 Jakub Moc (RETIRED) 2006-09-04 01:51:15 UTC]

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

[Comment 2 CPUShare 2006-10-13 19:02:26 UTC]

Created attachment 99622 [details, diff]
coreutils works for me

I also had very weird su troubles not picking up the environment with the shadow package that gentoo uses for su, sounds like su in shadow is broken.

coreutils works fine. Not sure why to prefer shadow to GNU coreutils, I wouldn't spend time trying to fix shadow, other distro use coreutils too. The less deviation there is the better, even if this may not be a strict su bug.

[Comment 3 CPUShare 2006-10-14 07:21:49 UTC]

Created attachment 99656 [details, diff]
I had to apply this patch to enable pam

every other distro is obviously applying it too and original shadow package also was obviously linked against pam. Quickest link returned by google was this http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/coreutils/coreutils-5.93-pam.patch.bz2 and that's the one I added to the coreutils-patch tar.bz2 package.

[Comment 4 CPUShare 2006-10-14 07:26:33 UTC]

Created attachment 99657 [details, diff]
here the new tweak to the ebuild to apply and enable pam if pam use flag has been specified

theoretically the pam.d/su should also move from shadow to coreutils but that's a less interesting change and it doesn't matter where pam.d/su comes from since it's the same file contents. Perhaps coreutils-darwin will choke after this change, dunno, but if coreutils-darwin is so good that somebody may prefer it to GNU coreutils, for sure it has to ships a better su too, right? ;-)

[Comment 5 SpanKY 2006-11-12 21:29:31 UTC]

Comment on attachment 99656 [details, diff]
I had to apply this patch to enable pam

we're not touching coreutils

[Comment 6 CPUShare 2006-11-18 02:27:48 UTC]

if you're not touching coreutils you definitely need to fix su in shadow.

Please try to add a 'echo ciao' in your normal user .bash_profile file. Reproducing this annoying bug is very easy:

cpushare ~ # echo echo ciao >> ~andrea/.bash_profile
cpushare ~ # su andrea -c /bin/true
[ so far so good no login shell ]
cpushare ~ # su andrea             
andrea@cpushare /root $ exit
[ so far so good no login shell ]
cpushare ~ # su - andrea             
ciao
andrea@cpushare ~ $ logout
[ so far so good login shell ]
cpushare ~ # su - andrea -c /bin/true
cpushare ~ # 
[ bug triggers, login shell but when -c is specified it doesn't read the .bash_profile ]

The arg0 has to be set to -su for bash to do the right thing. For whatever reason I don't understand. Coreutils gets that right (it only requires the pam patch to be feature complete like shadow, at least coreutils su isn't buggy like this).

I had to fix a _tons_ of scripts adding ugly hacks like 'su - user -c ". ~/.bashrc; command"' to make it work on buggy su.

[Comment 7 CPUShare 2007-02-25 20:56:04 UTC]

nobody seems to care that 'su - user -c' prevents bash to load its .bash_profile despite a login shell should do it... oh well. you're not touching it, but su from coreutils never had that problem ;)

[Comment 8 Robin Johnson 2008-12-07 08:14:03 UTC]

Debugging su indicates that shadow is removing the following from the environment, regardless of -m. Look in shadow-4.1.2.2/libmisc/env.c:

static const char *forbid[] = { 
    "_RLD_=",
    "BASH_ENV=",        /* GNU creeping featurism strikes again... */
    "ENV=",
    "HOME=",
    "IFS=",
    "KRB_CONF=",
    "LD_",          /* anything with the LD_ prefix */
    "LIBPATH=",
    "MAIL=",
    "NLSPATH=",
    "PATH=",
    "SHELL=",
    "SHLIB_PATH=",
    0 };

I'm uncertain of correctness, esp in the case of su from root to a user.
vapier: your call, should sanitize_env() be called in su.c if -m is passed?

[Comment 9 SpanKY 2008-12-07 09:19:49 UTC]

the same behavior occurs in sudo and is not controllable.  i dont think we should change one without the other.

that said, i imagine the same trick for sudo will work for su:
sudo env PATH="$PATH" ...

[Comment 10 Steven Parkes 2009-05-31 03:19:13 UTC]

(Don't know if it violates protocol to comment on a resolved bug?)

I just got bit by this. In particular, yes, -m/-p does not preserve PATH (at least root->user) which I can live with but probably should be documented?

But more bizarrely, you get a big difference depending on whether PAM is enabled. In particular, if you -m w/PAM, the result has no PATH at all. It's not getting set to the user default, e.g.,

# su root -c printenv | fgrep PATH
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# su -m root -c printenv | fgrep PATH
# 

With limited testing, this looks to be an upstream thing? But for some reason (again, limited testing) It's not happening on Jaunty (and I don't know how to decipher their patches against upstream.)

I suppose I could submit upstream, but it'd be nice to get a sanity check, first ...