[systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Tue, 22.07.14 18:35, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Lennart Poettering at 22/07/14 12:10 did gyre and gimble:
> >> > I guess it's OK to do this kind of user lookup stuff from the journal
> >> > code (i.e. server_fix_perms())?
> > Hmm, yuck. Actually it is really difficult....
> > ...
> > Bummer, not sure if we can save this idea...
> 
> Yeah, I did wonder about it when you suggested it!

Talked to Kay about this a bit more. Here's an idea:

There are basically three areas where the system vs. regular user UID
boundary matters:

a) in journald for splitting up journals for individual users
b) in the coredump hook, for similar purposes
c) in sysusers when creating new system users

Solution for a): add a new configuration option to journald.conf for
declaring the UID range to split up journals in. Usage like this:
          
          SplitUserRange=1000-65533

Solution for b): similar, but an option for coredump.conf

Solution for c): a new "r" directive or so for the sysusers snippets
that declares ranges to allocate new system users from:

         r - 200-999

In all three cases, if the setting is not set, we default to the
configure time boundary (1000) as before.

To make this generic, we'd actually allow people to configure multiple
ranges freely:

       SplitUserRange=1000-2000,10000-6533

or for sysusers.d

        r - 200-700
        r - 800-999

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?

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.

Lennart

-- 
Lennart Poettering, Red Hat