[systemd-devel] sysusers and login.defs checks

Colin Guthrie gmane at colin.guthr.ie
Wed Jul 23 13:22:54 PDT 2014


Lennart Poettering wrote on 23/07/14 18:31:
> 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?

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

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.

Ultimately, I guess really don't care much about it. For fresh installs
it's kinda moot, but that said, login.defs is fairly well known and I
really just don't grok the aversion to using it if it exists.

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)

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

Yeah that's one advantage, but I don't really see why this is any better
than just *one* configuration value (e.g. SYS_UID_MIN) in one
configuration file (e.g. /etc/login.defs) which is already honoured by
shadow-utils and no doubt other tools too.

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?

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/


More information about the systemd-devel mailing list