On Wed, Jul 23, 2014 at 1:49 PM, Colin Guthrie <gm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel