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
*** Bug 146230 has been marked as a duplicate of this bug. ***
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.
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.
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 on attachment 99656 [details, diff] I had to apply this patch to enable pam we're not touching coreutils
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.
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 ;)
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?
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" ...
(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 ...
