New Fedora 22 Change proposal: systemd-sysusers

[Miloslav Trmač]

(This is all rather beside the point: fixing those particular things won’t eliminate any of the problems of triplicate implementations and splintered knowledge.  But to spread the awareness of the area…)

----- Original Message -----
> On Wed, Jul 9, 2014, at 07:30 AM, Miloslav Trmač wrote:
> 
> > * validates names incorrectly
> 
> We're talking about the equivalent of lu_name_allowed() from libuser?
Yes.

> But the usernames specified here are only for system users, they're not
> derived from dynamic input, so it seems to me we can be even more
> restrictive safely.
True; to that extent this is not such a pressing problem.

> Can you be more specific about the name validation?
The binding maximum length constraint is from the utmp format (UT_NAMESIZE - 1); LOGIN_NAME_MAX is an upper bound but not binding, and this has already ended up in systemd-sysuser’s documentation essentially promising to do the impossible/unsafe by using the non-binding maximum length.

> > > * breaks the configurable [UG]ID_MIN logic
> > (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that
> > is actually used and needed)
> 
> It *does* read that file since:
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=f7dc3ab9f43b67abcbd34062b9352ab42debec49
> This predates sysusers, but I'm assuming you mean the bug here is that
> it's read at build time and instead should be dynamic?

Yes.

> > * is likely to break various readers software by not updating the shadow
> > files
> 
> There was a discussion of that upstream, it's on the TODO.  I agree with
> Lennart here that it seems nicer to just not have entries at all,

On a typical system _no_ accounts are misssing from the shadow files, so tools and admins’ scripts are not designed and rigorously tested to handle this.  (Early in its history, system-config-users had a _lot_ of problems with shadow/non-shadow mismatches.)

Note also that if a tool needs to edit _one_ field within the shadow file, it needs to add some values for all the other fields (or at least the mandatory ones), and it’s not always obvious what value to use.  So it’s actually much clearer for the system tools, which already know the default values of the fields based on their own configuration, to pre-create the shadow entries with the correct default values.  (Though this applies especially to real users rather than passwordless system accounts.)

> > * doesn’t do any auditing.
> 
> I don't see libuser doing any either?  Am I missing it?

No, it’s also missing I’m afraid.


> > We are currently already in a bad position by having two major
> > implementations of maintaining the critical databases, we absolutely
> > don’t want any more.
> 
> Those two being libuser and shadow-utils?

Yes, to my knowledge.

> > At this point this means systemd-sysuers should either run the
> > executables from shadow-utils, or link to libuser.  (Or, I suppose, use
> > accountsservice, but that ends up calling shadow-utils.).
> 
> Hmm.  Well, I do see a key distinction here being between system and
> non-system accounts.

The two are distinct, but that doesn’t justify having three different writers with different policies maintaining a single database, for either of the cases.

> In that case, I don't see significant
> complexity or cost to having multiple readers/writers.

The cost to write the new code in systemd-sysusers is already way larger than what would have been necessary to just call useradd, so it is inefficient by that measure already.  Then add this discussion, and making any future changes in the design more costly (like your proposal for /usr/lib/passwd - one more implementation is one more place to patch; every future change would be all that much harder)
    Mirek