New Fedora 22 Change proposal: systemd-sysusers

[Colin Walters]

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? 
Something like the
/* Allow trailing $ for samba machine accounts. */
?

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.

Can you be more specific about the name validation?

> * 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?

> * 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, but if
it breaks some checking tool, doesn't hurt to add it either.

> * doesn’t do any auditing.

I don't see libuser doing any either?  Am I missing it?

> 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?

> 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.  There's clearly a need for unification and caching
around all of the many ways in which admins might want to store and
manage non-system accounts, and I see SSSD providing a lot of value
there.  But system accounts are a lot more restricted; and we're not
discussing (now) having them anywhere other than /etc/passwd in the
traditional format, correct?  In that case, I don't see significant
complexity or cost to having multiple readers/writers.