[systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Wed, 23.07.14 20:50, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 
> On Wed, Jul 23, 2014 at 07:31:31PM +0200, Lennart Poettering wrote:
> 
> [snip]
> 
> > Now, this alone wouldn't provide compatibility with the dreaded
> > login.defs file. For that we'd then employ a postinst script that reads
> > the range from the file, and then automatically generates a sysuers.d
> > drop-in or a patches journald.conf and coredump.conf should the range
> > not match the default.
> > 
> > Does this make sense?
> Seems like a great big effort to avoid reading a simple configuration
> file.
> 
> When people want to teach systemd to generate dynamic configuration
> based on some other configuration, to pass commandline options and/or
> environment variables to a daemon that is starting up, because the
> daemon cannot do it on its own, we always tell them: teach the daemon
> to do that on its own. We should apply the same principle here, and
> not spread the configuration over n automatically generated files.

Well, I'd feel easier about it if I actually believed that the
configuration file login.defs was well designed and not just completely
drowned in legacy UNIX cruft... 

Also note that the additions I propose actually don't just make the
boundary configurable, but are a lot more generic than that. They make a
subsystem-specific logic configurable, that is by default sourced from
the UID boundary, but it's not the UID boundary you configure.

Hence, the nature of the configuration changed quite a bit. Instead of
making the UID boundary configurable (which I find really wrong
conceptually, because it shouldn't be the choice of the admin, but of
the vendor), we explicitly allow the logic normally based on it to be
configured, natively.

It is philosphically quite a difference whether we expose "SystemUIDMax=" as
journald.conf option or whether we expose "SplitUserRange=" as I
propose. The former would be strictly a duplication of configuration
already existing in login.defs. The latter is much more generic...

Or try to see it from a different perspective: we already introduced
multiple SplitMode= settings, since people wanted to split up non-login
user journals too (we added that on request of David Strauss). A
weakness of those models so far was that this meant that either they get
everything split up, or just the login users, which is usually much too
unprecise. Usually what's actually desired is to split out login users
plus a certain additional range of users used to run multiple httpd
instances or so. With the configuration options I propose you can do
that.

> > As a side effect this would actually even allow us to be closer to
> > FEdora's current bheaviour, since it reserves UIDs < 200 for static
> > assignment, which we could then easily exclude from theis logic, too.
> In practice this might not be useful, because even if all the 800 UIDs
> starting from 999 were used up, it would be better to encroach on the
> "static" range than to fail.

Well, hopefully the static UIDs are static for a reason: they are UIDs
that might write files to NFS accessible shares. It might be a better
choice to fail the addition of the system users than to allow the wrong
networked users access...

But anyway, I personally wouldn't bother with statically assigned UIDs,
but then again, I can understand why Fedora has the policy on this it has.

Lennart

-- 
Lennart Poettering, Red Hat