[systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

Lennart Poettering wrote on 24/07/14 11:59:
> ...
> snip
> ...
> I am pretty sure you will find people who will defend some of this
> non-sense, but honestly, this is all is stuff that shouldn't exist.

OK, that was a fairly convincing message! Many thanks for taking the
time and being so explicit.

I now appreciate why the journal/coredump splitting is desirable and why
it can/should be different from the sysusers range (and from each other
too).


That said, I'm still not convinced that it should be a simple setting in
journald.conf only. If a package wants to install a service with it's
own user and explicitly wants it to have it's own journal (is apache
httpd a good example of this? Dunno, but it's conceivable either way!),
then they would need the appropriate sysusers.d snippet but then they'd
also have to either manipulate the journald.conf file's SplitUserRange
line or use a dropin file that some generator uses to manipulate and
configure the line accordingly. This just feels a bit too clunky.

Would there be a a way to somehow keep SplitUserRange for basic
(administrator) overrides, but also parse e.g. a column in the sysusers
file to specify whether or not that user wants it's own journal [and
another column for coredump]? The SplitUserRange setting could have
syntax that allowed the admin to either extend the info found in
sysusers (which would be the default), or explicitly override some
setting. e.g.

Say I wanted a split journal for UID 99 (a manually created system
user), I could just say:

  SplitUserRange=99

and all the packaged preferences in sysusers files would still be
honoured in addition to UID 99.

If the sysusers file for apache's httpd had:

  u httpd 440 "HTTP User" y

where "y" is the new "split journal" column, but I, as an admin, wanted
to override that, I could just specify:

  SplitUserRange=99,-440

The leading "-" means "remove range".

Of course an alternative would be to just override the sysusers file in
/etc and put an "n" instead of the "y" (or leave it out), but there may
be a desire for the admin to override all the journal splitting easily
by doing something like:

  SplitUserRange=-1-65535
or
  SplitUserRange=-*



It's maybe crossing a boundary (i.e. journald should maybe not be
parsing sysuser's config files?), but it would certainly simplify
packaging and avoid the need for the "config patching generator thingy".



Iff it's OK to parse sysusers config from journal [and coredump] stuff,
then perhaps it's also OK to parse it from shadow-utils? If so, then
this is one step closer to your goal of killing login.defs. If direct
parsing is NAKed perhaps it could just shell out to a
systemd-sysusers-getnewuserdetails command which spat out a uid:gid pair
(and took an optional --system argument), that way the parsing logic
only needs to live in one place. This is obviously pretty racey, but I
guess shadow-utils should really do some kind of locking on the files
anyway. I've no idea if/how all of this would work when hooking things
up to e.g. LDAP (I'm not even sure adduser+friends can do that?)


I guess my main concern still remains that uid range settings for system
users would now be in two places - one used by sysusers and another by
adduser (I now accept your argument that the other two places are
different configuration data even if it's conceptually similar). I want
to be able to tell a user that the configuration is in one place not
explain that package "system users ranges" are in one place and
adduser's "system user range" is in another.

Of course I'm assuming here that shadow-utils and it's adduser commands
are still expected to be around for a while... perhaps this is
considered legacy too these days (not sure what the replacement would be
tho'!)?


Sorry if this thread is getting a bit annoying, but I am convinced by
most of the arguments now!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/