[systemd-devel] sysusers and login.defs checks

Kay Sievers kay at vrfy.org
Wed Jul 23 05:22:59 PDT 2014


On Wed, Jul 23, 2014 at 1:49 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Kay Sievers wrote on 23/07/14 12:36:
>> I don't see the rather artificially constructed case of an
>> /usr/share/factory/etc/login.defs + tmpfiles snippet to copy to /etc
>> as a valid argument for reading login.defs.
>
> Well, my point was that one of Lennart's original arguments for NOT
> reading login.defs was that /etc/ wouldn't have it when bootstrapping.

The main point was that it should not be *configurable*, but be a *static*
OS property.

Unix/Linux is just so insufficient and broken regarding the uid
namespace and handling, that we should limit ourselves to the simplest
rules possible and live with it, instead of trying to fix something that is so
broken that it can never work properly with all the options people like to
throw at it.

> But as you've just confirmed if you *are* bootstrapping /etc, then using
> the compiled in defaults makes sense as you are very unlikely to be
> copying across a factory version of login.defs anyway. My point was that
> if you WERE copying across of a factory version of login.defs it should
> really be setup with the same defaults that systemd has compiled in anyway.

Right, anything else would just be broken. Copying login.defs at bootstrap time
would not make any sense in the first place. But, hey, it would be just one of
thousand ways to break a setup. It's nothing we need to care about.

> So again, this is just furthering the argument that we *should* read
> /etc/login.defs at runtime and the "bootstrapping" argument for not
> doing so is not really valid.

No, I still think we should limit the options of the conceptually completely
broken idea of unix uids to the absolute minimum, and not try to fix things
in any way here with layering even more broken options on top.

If we want uids that have meaning and can be managed, they should
become 128 (uuid) or at least 64 bit, so they can be statically
allocated and moved
from one machine to another.

The sysuser vs. normal user is really not significantly more that a convenience
feature, it is not used for authorization or anything. Legacy setups
on new systems
might end up with fewer convenience features, but there are no
features lost really,
which they had before systemd was used.

Kay


More information about the systemd-devel mailing list