New Fedora 22 Change proposal: systemd-sysusers

[Lennart Poettering]

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

> > Yeah, because we dodn't want to intrdocue any new API we have carefully
> > made sure that whenever we write pasword, group and shadow files we use
> > existing APIs from glibc, more specifically putpwent(), putgrent(),
> > putspent() and crypt_r().
> 
> > This is about creating system users, not normal users, hence using
> > anything more fancy than glibc's native APIs is wrong.
> 
> I have already given examples where using a higher-level API would
> avoid mistakes _and_ make future changes easier; and none of the
> reasons offered convince me:

Well, there appears to be no higher-level API around. You are saying
yourself that libuser is going away. It's also not OOM safe, pulls in
the glib dependency, it bypassed the low-level glibc APIs. So I am not
sure what you are telling me with that...

We use the only widely established API there is, and that has a future,
that is documented (though not parcitularly well), that is OOM safe,
doesn't pull in any deps, and is pretty much exactly as low-level as we
need it. That's glibc. I really don't see any other option here.

> > It appears to me that libuser unsuccessfully duplicates APIs from glibc,
> > shadow-utils and other packages.
> 
> Yes, it only duplicates a glibc API if we ignore all the code that
> isn’t in glibc, including all the things that systemd-sysusers got
> wrong; and shadow-utils doesn’t have a C API so libuser doesn’t
> duplicate a shadow-utils API.

Well, You should be aware that sysusers is less than a month old and has
been part of a systemd release less than a week ago for the first
time. If the only thing you could find is the user name length thing,
the lack of updating of shadow and that we lack audit (which libuser
also lacks), then I think we did a pretty good job so far...

> > I mean, it's quite weird to have both
> > "passwd" and "lpasswd" around, and then complaining to me that we don't
> > need multiple implementations. I mean, I really don't understand why
> > there are two implementations of this in the first place!
> 
> I was not proposing to call the libuser command-line tools, so I don’t
> think they are relevant.  I agree it is not good that there are two
> implementations, and as I already wrote, there is a plan (and people
> assigned to it) to fix this.

Well, the plans are vague, involve daemons and stuff, and from all I
heard are really not the right thing for a minimalist early-boot tool
like systemd-sysusers...

> > Also, note that with systemd we try to find solutions that work for most
> > Linux distributions. libuser appears to be quite common on Fedora, but I
> > am pretty sure that systemd is not the vehicle to make it standard on
> > other distributions too, in particular via such a relatively auxiliary
> > feature of systemd.
> 
> systemd has been happy to make so many different things de-facto
> standard that I can’t see this being an outlier.

Well, we can push stuff with systemd, sure, but it has to be convincing
if we do it, we must be able to make a strong case. And quite frankly,
you really didn't sell libuser so well, so far... I mean, you are even
saying that it will go away...

> 
> > Good! We just use glibc APIs for writing those files. If you want only
> > one implementation, why not get rid of libuser, and stick to glibc? ;-)
> 
> Because the glibc API is not at all the right one.  (Way too low-level
> as systemd-sysusers has successfully demonstrated; impossible to add
> more fields; enshrines old bad design decisions, like having password
> expiration in 24-hour granularity.)  Considering the actual library
> name is completely irrelevant, having the new API written and
> maintained by people whose _primary occupation_ is to understand
> accounts and identities seems like a good enough reason to have it
> done by sssd maintainers, as a library included within that project.

Well, you know, "systemd-sysusers", as the name says is a tool solely
for registering system users. Sure, the glibc API might not be the best
in the world, but it does do the basic bits that we need it to do just
fine.

And the thing about "primary occupation" I can only read that you are
telling me to stay off your lawn, because I don't understand
stuff. 

> And yes, the plan is to “get rid of libuser”, or rather to only have
> it a shim layer over the new sssd API.

I am sorry, but I really don't see system user registration in the
early-boot as something I would ever entrust in a full flegded sssd-like
thing.

Please understand that we are not duplicating "adduser" here. Already in
the name of the tool we wanted to make clear thtat this is abotu system
users, nothing else. The file format we defined has been reduced to the
minimum possible, in order to make it difficult for people to use it for
anything else than this (for example, you cannot set a shell for a user
with this, as system users are not suppoed to be logged into, unless the
admin later on manually sets a password and a shell).

An API that wants to implement a fully-featured "adduser" command of
course needs to support backends for LDAP and stuff, no doubt. But this
is really not that. We have a much much more limited usecase for what we
do. We clarify that in name, and in the config file language we
use. It's two different things.

> > > 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.).
> > 
> > Sorry, I am not going to play your stacking game. This is supposed to be
> > simple, work in a minimal early-boot environment, and use stuff that is
> > commonly around on Linuxes, from embedded to servers. glibc APIs
> > are. libuser is not.
> 
> I would be perfectly happy if it called shadow-utils.  That’s 200 kB
> total, and definitely “commonly around on Linuxes”.

Well, shadow-utils doesn't have a C API, and it's overkill for what we
are doing, really. We just want to set up system users, with no
passwords and with no login shells. It's not what we want.

> Describing modularity, avoiding duplicate implementations, and keeping
> specialized knowledge private to specialized modules as a “stacking
> game” is not helping this discussion.

Well, we need to solve a very simple problem with sysuers, and we have a
very simple API for that in glibc, and hence it appears clearly the
right decision for us to use glibc. 

I can see that you disagree, but I figure we have to agree to disagree
on this. 

Lennart

-- 
Lennart Poettering, Red Hat