[systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/07/14 03:16 did
gyre and gimble:
> I agree. Not reading /etc/login.defs makes the tool troublesome for
> existing installations.
> 
> I've experienced a related problem, where coredumps would not be
> visible for my user on a Fedora machine which has been upgraded over
> many versions.  It turns out that the user had uid 500 or something
> like that, and systemd-coredump treated the account as as a system
> account.

Yeah, I see that the SYSTEM_UID_MAX define is used in a few places
(namely the journal and sysusers).

I guess this should be abstracted out and changed such that it reads
login.defs and uses that value at runtime.

That said, it's also not inconceivable that the login.defs is updated
but user accounts still exist that are in the 500-1000 range. So perhaps
we should consider adding the same kind of heuristics for handling the
500->1000 jump that accountsservice has[1]? i.e. we add a
is_system_user() utility function or similar where this heuristic can be
an optional thing (like in accountsservice). What are the thoughts here?
IMO, I'd say that we should just honour login.defs and forget about
heuristics - anything upgraded should keep it's old login.defs values
and not update them. Only if you do a fresh install or manually renumber
your users should you change login.defs otherwise strange things will
happen to you (e.g. on login screen user lists, in user editing GUIs, in
coredump handling and other places). WDYT?




Also, while SYS_[UG]ID_MAX is currently parsed from login.defs during
configure, and I proposed to fall back to [UG]ID_MIN-1, I notice a few
things...

[I'll drop my "[UG]ID" syntax from now on... assume it's there!]

1. When the bump from 500 to 1000 was done in Fedora[2], SYS_UID_MAX was
added. But SYS_UID_MIN was also added. We do not currently parse this,
but perhaps we should and sysusers should refuse to work if we cannot
find a suitable UID to allocate?

2. Or perhaps we should consider whether the SYS_UID_MIN/MAX is useful
at all? Perhaps if not much uses it, it should just be killed off and we
should always just use UID_MIN-1?

Personally, I'd just go with 2 - the fact there are two settings to
represent a boundary point makes no sense to me - although there may be
valid reasons to leave a gap there?

Col


[1] http://cgit.freedesktop.org/accountsservice/tree/src/user-classify.c#n84

[2]
http://pkgs.fedoraproject.org/cgit/shadow-utils.git/commit/shadow-utils.login.defs?id=5d7612da5b7be0c7ce8bad72c4d69a8f347696db


-- 

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/