New Fedora 22 Change proposal: systemd-sysusers

[Lennart Poettering]

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

> ----- Original Message -----
> > Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
> > wrote up a Change:
> > 
> > https://fedoraproject.org/wiki/Changes/SystemdSysusers
> 
> A move to something more declarative makes sense (whether in systemd or through some kind of long-expected declarative rpm facility doesn’t matter to me much.)
> 
> The sysusers tool _really_ needs to use an existing API to manage the
> user database, though.  

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. This is not stuff
which is supposed to land on an ActiveDirectory server or so. It's stuff
we need to be able to recreate during earliest boot, before the first
daemons start, where little else but the most basic file system is
around. libuser is not useful for this kind of environment.

It appears to me that libuser unsuccessfully duplicates APIs from glibc,
shadow-utils and other packages. 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! 

Anyway, I can understand the reason for libuser's existence, but for the
low-level stuff we do with systemd here this is simply not the right
tool for the job. We want something so low level that glibc is the only
right option.

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.

> As it is, the implementation
> * validates names incorrectly

How so? Can you elaborate? Point me to normative documents?

> * breaks the configurable [UG]ID_MIN logic
> (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
> that is actually used and needed)

Well, this is something I really don't like. THis limit should be
compile-time configurable, but not runtime-configurable. This is
something the distributor needs to decide on, not something
administrators should be able to change without recompiling.

With systemd we kinda need to get something that works for the big
picture, and I have doubts that this is something I want to see in the
big picture, sorry.

> * is likely to break various readers software by not updating the
> shadow files

Well, we don't update the shadow file, since a missing shadow entry is
actually interpreted the exact way we want it here: as a disabled
account, with no password set, where it is not possible to login
to. That's the absolute correct default for system users.

That said, it was brought to my attention that "pwck" doesn't agree with
that. So I figure we'll update the shadow file too, the patch should be
easy. It's on the todo list.

> * doesn’t do any auditing.

Well, looking forward to a patch to add this.

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

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

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

> The plan is to have a single implementation, living around sssd.
>     (Jakub knows more.)  Either of two API points above are planned to
>     use the sssd implementation, so can be relied on long-term.  Mirek

I am sorry, but to make this very clear: sssd has not place in early
boot or in smaller setups. The problems we we want to solve with systemd
we try to solve generically, and this means that I am not telling people
to pull in sssd into the smallest of devices.

sssd/libuser is fine for creating nomral users with, and fine for
late-boot stuff, and fine for bigger setups. But other than that, glibc
wins the day.

Lennart

-- 
Lennart Poettering, Red Hat