Re: systemd fails to parse user that should run service

[Daniel Micay <danielmicay () gmail com>]

On Wed, 2017-07-05 at 16:37 +0100, John Haxby wrote:
> On 05/07/17 16:06, Daniel Micay wrote:
> > On Wed, 2017-07-05 at 15:50 +0100, John Haxby wrote:
> > > On 05/07/17 14:53, Simon McVittie wrote:
> > > > On Wed, 05 Jul 2017 at 14:02:23 +0200, Casper.Dik () oracle com
> > > > wrote:
> > > > > > 2) If user name specified in systemd unit file is
> > > > > > syntactically
> > > > > > correct
> > > > > > (according to systemd check) but user name does not exist
> > > > > > then
> > > > > > systemd
> > > > > > refuse to start that unit.
> > > > >
> > > > > Should systemd really valid usernames?  I would think that you
> > > > > would 
> > > > > either use getpwnam(username) and if that fails you may then
> > > > > parse
> > > > > it as a 
> > > > > numeric value.  If "0day" isn't a valid username according to
> > > > > getpwnam(), 
> > > > > when converting it to a numeric uid should *also* fail because
> > > > > "0day" 
> > > > > isn't a properly numeric value.
> > > >
> > > > It *does* fail. The problem is in the handling of that failure.
> > > > systemd
> > > > interprets that failure as "this line is nonsense, so behave as
> > > > though the
> > > > line didn't exist" rather than "this line can be positively
> > > > identified as
> > > > an attempt to name a nonexistent or unacceptable user, so fail
> > > > to
> > > > load
> > > > the unit". So User=7up does the same thing as User=0day - it
> > > > doesn't
> > > > run as uid 7, which is 'lp' on my Debian system.
> > >
> > >
> > > And therein lies the problem.  "0day" and "7up" are valid user
> > > names
> > > according to Posix[1], they may or may not exist, but they are
> > > valid.
> > > You may think Posix is wrong to allow an initial digit, but that
> > > isn't
> > > the issue.  The problem is that systemd treats an "invalid"
> > > username
> > > as
> > > either an integer or not specified and in either case this results
> > > in
> > > a
> > > program running as the wrong user, probably as root.
> > >
> > > Having systemd balk at what Posix considers to be a valid username
> > > is
> > > a
> > > bug that systemd is free to say "this is stupid, we're not
> > > allowing
> > > that".   If, as appears to be the case, systemd says "that
> > > username is
> > > stupid, we're going to interpret it differently" then that's when
> > > we
> > > need a CVE because, to my mind on this hot and sunny say, that's
> > > systemd
> > > apparently doing something for security that it is not.
> > >
> > > jch
> > >
> > >
> > > [1]
> > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03
> > > .htm
> > > l#tag_03_431
> >
> > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c
> > #L49
> >
> > POSIX also says "." is a portable character, which isn't allowed by
> > shadow either. What are distributions using to provide useradd if
> > not
> > shadow?
>
> Interesting.  "useradd a.b" works on Fedora so I wonder what's
> different
> there?

It seems some distributions get useradd/userdel from somewhere else.

Maybe you have adduser from shadow? It'd be funny if they had different
rules enforced even for adduser vs. useradd...