[systemd-devel] sysusers and login.defs checks

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 23, 2014 at 11:29:20AM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Colin Walters at 22/07/14 21:47 did gyre and gimble:
> > On Mon, Jul 21, 2014, at 09:43 AM, Lennart Poettering wrote:
> >>
> >> I am pretty strongly against this. Making this administrator
> >> configurable apepars very wrong, this really should be a decision for
> >> the distribution vendor, and that's it.
> > 
> > You list one concern below, are there others?
> > 
> >>  We shouldn't design a system
> >> that comes to completely different results if you boot it up with and
> >> without /etc populated...
> > 
> > If that's the only issue, surely we could just have it in the
> > /usr/share/factory dir?
> 
> While I'm (personally) wanting to support login.defs here, there is
> still a chicken+egg that is not really resolvable here (AFAICT)
> 
> If there was a /usr/share/factory/etc/login.defs with e.g. 500 boundary
> point, then this file would presumably be copied in by tmpfiles to
> populate /etc/login.defs
I totally agree with Kay here, that /usr/share/factory is *only* for
programs which are broken and have neither compiled-in defaults nor
the ability to read /usr/share for their defaults. We should 
aim for empty /usr/share/factory/etc (*), and systemd certainly should
not depend or use anything in it.

And anyway, the file in /usr/share/factory/etc would have the same
defaults as compiled-in into systemd, so it is not useful. I think
that your angry chicken is not a problem.

(*) "Empty" files containing commented-out directives as a way of
documentation are fine.

> This was pretty much the same concern I had when Zbigniew patched
> sysusers to also look in /etc/sysusers.d/. The same chicken and egg
> scenario exists there, but Lennart was OK with it in that context.
> 
> To be honest, I'm not really sure why this chicken+egg is different from
> the sysusers one, so I'd expect either both to be rejected or both
> accepted but I'm not crazy fussed in this case as it should be easy
> enough to hack in /etc/login.defs parsing downstream where our primary
> use case is supporting "normal" installs where /etc/ is persistent and
> often upgraded from older releases.
The fallacy here is trying to support stateless systems with users.
Users (account numbers, their passwords, privileges) are state,
and the most important one at that. But the admin cannot expect to
nuke /etc and have working users, unless the users are defined
remotely.

I think it is fine to have locally defined users, and some way to
determine which of those users are "human". If the admin purges /etc,
the interpretation of which users are human resets to the compiled in
default. IMHO this is fine.

I like Lennarts idea of using 'user' group, since it is more flexible than
static ranges. It might be nice to support in the future if we work out
the details. But there's also a need for backwards compatibility. I know
from my own admin experience and agree with Reindl that UID changes are a
huge pain, and we have to support existing setups without requiring any
renumbering. This basically means that any distribution which supports
upgrades from previous versions will add /etc/login.defs support.

On Wed, Jul 23, 2014 at 02:22:59PM +0200, Kay Sievers wrote:
> No, I still think we should limit the options of the conceptually completely
> broken idea of unix uids to the absolute minimum, and not try to fix things
> in any way here with layering even more broken options on top.
Well, systemd uses the user/systemd boundary split in journald and coredump
permissions code, so we *are* layering on top. Even more importantly, we
are using it to allocate numbers in sysusers. Even with distribution
support, it is not possible to arbitrarily redefine UID ranges,
because users' UIDs are something that can be only changed by admin
intervention. I don't see how we can skip /etc/login.defs support
without doing a disservice to our users.

Previously we added the systemd-journal group. It was fine, because
it worked in a backwards-compatible way, and we could document that giving
users access to the journal can be done following a few simple steps.

Anyway, I think that /etc/login.defs support is made out to be something
much more complicated than it really is. IMHO we should:

- read /etc/login.defs and fall back to the compiled in value
- use whatever result we get in coredump, journald, and sysusers

It's not like the implementation would be hard, intrusive, or slow. It'd be
probably +3 lines in one or two places.

If we come up with additional heuristics or rules to determine human
accounts, we can safely add them in a backwards compatible way.

Zbyszek