Re: Bug#274229: System accounts with valid shells
On Thu, Jan 09, 2014 at 11:43:09AM +0000, Simon McVittie wrote:
> On 09/01/14 11:23, Colin Watson wrote:
> > In short, if you're using "su <user>" for any of the affected users
> > (daemon bin sys games man lp mail news uucp proxy www-data backup list
> > irc gnats nobody), and you weren't already passing an -s option, you
> > must add "-s /bin/sh".
> I wonder whether noninteractive su to drop privileges from root to a
> system account (in maintainer scripts, etc.) should be discouraged
> altogether, in favour of something with argv rather than shell
> semantics, like sudo/chrootuid? You can always get back from argv-based
> to to shell-based semantics by using "sh -c '<command>'" as the final
> arguments, if you really need shell command-line parsing.
I agree in general, but I prefer to make minimal changes for this sort
of fallout cleanup.
Unfortunately I think there's nothing in the base system with quite the
semantics one would desire (unless perhaps runcon does it, as you
suggest). In some limited cases it is also possible to abuse
start-stop-daemon, or you can even just write a short inline perl
script. See the history of man-db's postinst for how my own strategy
> runcon(1) in recent coreutils does appear to have the argv-based
> semantics, although I'm not sure whether it's (SE)Linux-specific; and it
> might be better to run in a clean environment too, like "su -" and (with
> default configuration) "sudo -H" do.
Yes, although I think creating a PAM session is generally overkill, and
using su/sudo for this kind of thing causes unnecessary syslog noise.
Colin Watson [firstname.lastname@example.org]