New Fedora 22 Change proposal: systemd-sysusers

Jakub Hrozek jhrozek at redhat.com
Thu Jul 10 15:18:26 UTC 2014


On Wed, Jul 09, 2014 at 10:30:27AM -0400, Miloslav Trmač 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.  As it is, the implementation
> * validates names incorrectly
> * breaks the configurable [UG]ID_MIN logic (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that is actually used and needed)
> * is likely to break various readers software by not updating the shadow files
> * doesn’t do any auditing.
> 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.
> 
> 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.).
> 
> 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

The effort Mirek is talking about (a not-too-detailed design page can be
found at [1]) aims at a) using the SSSD database primarily for user
accounts and b) providing a rich DBus API. We actually started with b)
because that's also usable and useful for remote (LDAP, AD, ..) users
which SSSD already handles.

The benefit of using the SSSD database would be the ability of use a
richer set of attributes that the passwd file has. The API would be
usable in a similar fashion accountsservice is now.

Even though SSSD would be in the business of managing local users, I
think the benefits of using SSSD are mostly for managing non-system
accounts. So from this point of view, I don't see what systemd is doing
as conflicting with what we plan on doing.

One issue to keep in mind is that we planned on reverting the order of
the NSS modules to "sss files". Given that systemd-sysusers would write
to the files directly with the libc API, we need to sync the changes
systemd-sysusers to SSSD database, otherwise we risk inconsistencies and
there would also be an extra round-trip to nss_sss before reaching to
nss_files. We /do/ plan on the syncing anyway, because some admins are
still used to vipw their passwd databases and there are legacy scripts
around, but still --  could we, when the SSSD interface is available,
call out from systemd-sysusers to the SSSD, with some fallback for cases
where SSSD is not running?

Are there any plans on changing any of the shadow-utils commands to call
out to systemd-sysusers when adding system users with either useradd
(useradd -r) or libuser?

btw I completely agree that even when we switch to using SSSD to manage
local accounts, the system must still be usable (sans the extra
attributes and the rich API..), if SSSD wasn't able to start for
example.
    
[1]
https://fedorahosted.org/sssd/wiki/DesignDocs/UsrAccountMgmtConsolidation


More information about the devel mailing list