I have the shell for the postgres set to /bin/false so the user cannot login. Attempting to run a command as that user, such as $ su postgres pg_ctl (as is done with the init.d script) simply fails. Changing the shell to something like /bin/bash fixes the problem. This functionality works on a Debian unstable system, so I assume it's something Gentoo is doing.
*** Bug 15222 has been marked as a duplicate of this bug. ***
This should be fixed in shadow-4.0.3-r4, please test and let me know: ------------------------------------------------------ nosferatu / # su nobody -c ls bin boot dev etc home lib lost+found mnt opt proc root sbin space tmp usr var nosferatu / # su - nobody -c ls nosferatu / #
I haven't tested this out, but I'm sure it will fix the problem for me. I'll let you know in a day or two. However, it doesn't seem like exactly the right solution. For instance, it explicitly specifies /bin/sh, when it might be preferable to default to the current shell instead. Also, it would presumably allow a normal user to su to a restricted account if the password were known, which seems like a bad thing. I've looked a bit at Debian's code, and it does the following: If pwent shell is null, default to /bin/sh If -s (shell) is specified, use that. Otherwise, if -m (keep environment) switch is used, set shell to genenv("SHELL") If pwent shell is restricted (not in /etc/shells) and uid is not root, set shell to pwent If shell has not been specified yet, default to pwent This behavior seems in keeping with the man page, which specifies that su will execute the user's shell, but it also allows root to su to a restricted account and run commands (by using either the -s or -m switch). I also have to apologize in that my initial report was slightly misleading. I stated that I was able to su to restricted accounts on my Debian system, but it turns out I had 'alias su="su --shell=/bin/bash"', which was allowing me to do so. I'd like to add this functionality to Gentoo. If I whip up a patch and it looks good, would you be willing to apply it?
Yes, you are right. I never looked at the manpage :/ We use su from shadow package, as Debian prob use from sh-utils. Yes, the shadow one do have a few less options, but do use PAM, so are more versetile to configure security ... the pam_wheel and pam_listfile for instance gives great flexibility to su. I think the best way to handle the 'su nobody -c blah' where the shell is /bin/false, will be to use sudo: -------------------------------------- workshop / # sudo -u nobody ls bin boot dev etc home lib lost+found mnt opt proc root sbin space tmp usr var workshop / # -------------------------------------- I will mask this su again, although in theory by the time it gets to spawning the shell, it have already done all the security checks, and should be ok. I do not however have the needed experience I think to audit it for security, so I will mask it. Thanks for your input and patience.
Actually, Debian uses the one from shadow also. They just patch it more heavily than Gentoo does. Saying 'use sudo' doesn't really do it for me, because it doesn't solve the core problem of init.d scripts wanting to use su to change uid to users with restricted logins. So you never really answered the question: if I port across this Debian functionality, would you be willing to apply it?
`su' from `coreutils' uses pam and has useful `--shell' and `--preserve-environment' options. I dont't understand why gentoo use `su' with minimal functionality instead more powerful version? P.S. At least SuSE use `su' from `coreutils' package.
