On Fri, Aug 2, 2024 at 7:21 AM Greg Wooledge <g...@wooledge.org> wrote: > > On Fri, Aug 02, 2024 at 11:35:58 +0200, Florent Rougon wrote: > > Which I am inclined to believe, although I'm reluctant to try 'su -p' > > for fear of creating a mess in my normal user setup: > > > > ~ % su -p > > Password: > > zsh compinit: insecure directories and files, run compaudit for list. > > Ignore insecure directories and files and continue [y] or abort compinit > > [n]? ^C > > I don't use zsh, so I don't quite understand what "compinit" means. > But, just looking at the su(1) man page: > > -m, -p, --preserve-environment > Preserve the entire environment, i.e., do not set HOME, SHELL, USER > or LOGNAME. This option is ignored if the option --login is > specified. > > The main issue here is likely to be the HOME variable. If you're running > a shell as root, but with HOME=/home/florent or whatever, then some of > the programs you start may create new dot files inside /home/florent/. > These files will be owned by root (because the programs are running as > root). Then, at some point in the future, if you run those same programs > as florent, you won't be able to change the contents of the dot files. > (You would, however, be able to remove them.) > > That's not a security hole or anything like that, but it might cause some > surprises.
emacs is notorious for that. In fact, if you install a new system, and `sudo emacs <some config file>`, then emacs will create its own config directory (.emacs/) in your home directory owned by root. I quickly learned to run emacs as myself before making adjustments to config files on a fresh install. > A secondary issue might be the mismatch between the effective UID (0) > of the programs you run, and the LOGNAME/USER variables (florent). Some > programs may act upon one, and some may act upon the other. Some may > even create a strange mixture of both. I don't have any specific examples > of this. See Chen, Wagner and Dean's Setuid Demystified, <https://www.usenix.org/legacy/events/sec02/full_papers/chen/chen.pdf>. > Realistically, what one *wants* from su is for it to override the HOME, > PATH, USER and LOGNAME variables. The version of su in Debian prior to > buster used to do that, and everything was peachy. The version of su in > buster and beyond no longer sets PATH by default. However, you can fix > that! All you have to do is create a one-line configuration file: > > hobbit:~$ cat /etc/default/su > ALWAYS_SET_PATH yes > > Then the buster+ version of su will behave sensibly, changing the PATH > variable to a standard one which includes /usr/sbin and so on when you > become root. Jeff
