[systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Wed, 23.07.14 21:22, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> > Does this make sense?
> 
> To be frank, I really don't think it does make much sense at all. I
> mean, something which is currently configured in one place and then
> used

Well, no, it's not the same setting that is configured at three
places. It's different things you configure. There's conceptually quite
a difference between these settings:

 a) Numeric UID boundary

and
 
 1. ranges sysusers dynamically picks UIDs from
 2. ranges where journald splits up journals
 3. ranges where coredump grant users access to their own coredumps

While #1 configures the part that by default is the bit "below" the UID
boundray, #2 + #4 configure the part that by default is "above" the UID
boundary.

Also, we allow people to actually take benefit of this. As mentioned in
that other mail, being able to configure which users precisely get split
up journal files can be truely useful...

The tools that made use of the UID boundary actually derived very
different things from it. sysusers defined the range to pick dynamic UIDs
from as 1..BOUNDARY. journald picked the range to split of journals
for as BOUNDARY+1..MAXINT-3. The former was simple but not even correct for
Debian nor Fedora. The latter is probably what we should do, but don't
even do (because the "nobody" user shouldn'get his private journal file).

With making the respective ranges explicitly configurable we hence allow
distributions to properly enforce their own policies, and we add true
value to admins. All that while not blessing the crufty /etc/login.defs
file as something we officially want to support in legacy-free systems.

The more I think about all of this the more I actually get convinced
that making the ranges explicitly configurable for their respective
purpose is the right thing to do. I mean, the concept of numeric 32bit
UIDs on UNIX is seriously broken, in particular when it comes to
assigning meaning to specific ranges. Any better designed OS would have
used a namespace that requires no explicit managing (such as UUIDs), and
defined context via true metadata about the users, rather than
mathematical range expressions.

Now, because the namespace is so small, and because semantics have to be
derived from the numeric range a UID is in, I really find it beneficial
if we expose all that logic to the admin/vendor/user, then to strictly
enforce a way too simple view on things, where everything below some
value is one thing and everything above is another thing. In particular
since such a model cannot cover the special cases of UID 0, MAXINT-1,
MAXINT-2.

We have seen now that Debian defines at least 5 ranges with specific
semantics, and Fedora has at least 3 too. In the future we'll probably
see even more ranges, for example for dynamic UID allocation for things
like containers. Trying to cram this all into a single value can never
work.

Or to make this more explicit: somewhere on my TODO list is adding a
mini daemon and NSS module that can dynamically hand out UID ranges for
tools like nspawn for usage in UID namespacing. That daemon would also
have a configuration file. In that configuration file we'd have to
configure an explicit range it shall use. That range is probably going
to be something like 40000-50000 by default, i.e. very far away from the
boundary...

> in tools such as shadow-utils when creating users (both with and without
> -s) now has to be configured in three *additional* places. That hardly
> seems like an improvement and sounds like a recipe for misconfiguration.
> It just makes it more convoluted, where essentially the same data is
> repeated in multiple places and then you have some crazy config file
> patching system on top of that to distribute it to all those places.

It's very different data actually.

> If you were to suggest some new shared configuration file and we could
> update shadow-utils and friends to use it then fine (seems kinda
> pointless tho'), but I really don't get the logic here.

Well, login.defs might have configuration options to tell adduser from
which range to allocate regular and system users from, but it doesn't
have options to configure in which ranges to split up journal files,
in which ranges to provide access to your own coredump files, and from
which ranges to allocate dynamic throw-away UIDs for user namespacing
from. And it shouldn't have, as much of that is logic specific to the
subsystem, and is not orthogonal (by which I mean, that where to split
up journal files might or might not have overlapping ranges with where
to allocate system users from, if you follow what i mean).

> I'd rather we just refactored systemd to have a utility function
> "is_system_uid()" or such like which just does the compiled in default
> check as it does now (no functional change to how it works now, just
> centralised) and then I can just hack in reading and honouring
> login.defs into that utility function in a downstream patch. It would be
> a couple lines of code and very easy to support downstream if you are so
> against it. I'm not against a compiled in default (that's what
> shadow-utils does too after all)

Well, it wouldn't be that. sysusers would have no benefit of
is_system_uid() for starters, it never asks that question. And I am very
convinced that allowing configuration of when to split up
journals/coredumps is something that should probably default to a range
of BOUNDARY+1..MAXINT-3, but be changable by the admin.

> This seems a case were your suggesting a change for changes sake rather
> than just saying fine, login.defs is as good a config file as any for
> picking vaguely sane defaults. Perhaps I'm missing some background as to
> why login.defs is such a horrible config file?

Have a look at the man page, for starters. At least this is cruft:

- the bits about "finger"
- the bits about "console"
- the bits about HZ
- the bits about supath
- the bits about TZ
- the bits about eraschar, killchar
- the bits about ftmp or hushlogins
- the bits about making the issue, motd, nologin file configurable
- the bits to configure what to log
- the bits about the login prompt string
- the bits about MAX_MEMBERS_PER_GROUP (not even compatible with shadow-utils itself)
- the bits about MD5_CRYPT_ENAB
- the bits about "obscure checks"
- the bits about "porttime"
- the bits about deriving ulimit/umask from GECOS
- the bits about suname, sulog...
- the bits about ttygroup/ttyperm (this is not configurable, and hasn't been for a long time)

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.

Lennart

-- 
Lennart Poettering, Red Hat