[systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Mon, 21.07.14 13:11, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> 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?

I am much more open about code that magically detects where the boundary
is, when allocating a new system users... But I don't see how this could
work in real life. The accountssserice code doesn't appear too
convincing to me... There are system users with login sheels, and there
are normal accounts that have been disabled, I really don#t find a logic
bound to either of that particularly striking I must say...

What could work better is to check the home directory. If it is "/" or
something in /var we can be reasonably sure that something is a system
user, but if it isn't we have no clue...

> 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?

As i understand the current stuff in Fedora's login.defs, the idea is
that 1-200 is left for statically assigned system users, 201-999 for
dynamically assigned system users, and 1000-60000 for normal users.

Based on this, static system users are allocated growing from 1 upwards,
dynamic system users are allocated growing from 999 downwards, and
normal users from 1000 upwards.

In sysusers we don't care much abotu the actual ranges, we just allocate
from some specified start value downards, and that start value is a
compile time option, that defaults to 999 or is SYS_UID_MAX from
login.defs, should that be available...

Lennart

-- 
Lennart Poettering, Red Hat