New Fedora 22 Change proposal: systemd-sysusers

[Lennart Poettering]

On Wed, 09.07.14 12:25, Miloslav Trmač (mitr at redhat.com) wrote:

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

Oh, well. If utmp really is the normative source for this then that's
quite a pity, in particular since this appears not to be documented
anywhere, even though people care quite often what the maximum length
for usernames is.

If 32chars as required by utmp is really the limit we should follow
here, then I would really enjoy if we'd actually set LOGIN_NAME_MAX to
the same value.

Anyway, I have now added a check for UT_NAMESIZE-1:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=932ad62b84165b0acf690ea34c4b8083657ae244

> > 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.)

Well, we use glibc APIs. It would be good to document this in the
respective manpages, most specifically putspent(3). Thanks.

Hmm, it would be good btw, if libuser would actually use glibc APIs, for
the precise reasons you are pointing out. As it appears though you
reimplemented all those APIs for no reason...

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

Well, sysusers is on the safe side here, we appear to be the only ones
who actually use the lowest level APIs for this, there are, which are
glibc's, but I figure I am repeating myself now...

> > 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 yourd
> proposal for /usr/lib/passwd - one more implementation is one more
> place to patch; every future change would be all that much harder)
> Mirek

Well, userass/adduser are something the distros currently deviate
greatly in, and we needed somethign simple, safe, somewhat vwidely
available and capable of running in earliest boot. The glibc APis
provide that, no other API does that.

Oh, also, libuser is a glib API. Nothing against glibc, but for the
low-level stuff we do that runs with nothing around we try to be OOM
safe, and stuff...

Lennart

-- 
Lennart Poettering, Red Hat