On Wed, 23.07.14 21:22, Colin Guthrie (gm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel