On Di, 14.01.20 15:55, Michael Biebl (bi...@debian.org) wrote: > Lennart, Zbyszek, > > what's your take on this? > > For some more background, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905817 > and the recent discussion at > https://lists.debian.org/debian-policy/2020/01/msg00013.html
I glanced over these discussion only superficially. A few notes: 1. We document our numeric UID/GID expectations here: https://systemd.io/UIDS-GIDS which you already found. 2. I'd strongly advise you to stick to 16bit UIDs allocations for Debian's base OS (i. 0…65534). In userns container environments you can assume to get at least 16bit but only in some envs you'll get more. If you want to be compatible as payload with such envs without trouble you can't really use more hence. 3. Regarding naming: in systemd our own users are nowadays all prefixed with "systemd-". Besides that there are a couple of system users/groups beyond that defined ("audio", "video", and so on) which have not changed much in the past. They are not set in stone, but they certainly don't gain new names any time soon. The only addition we made in recent years was "render" as a group. I think primarily we should leave non-prefixed user/group names to the users of the systems, so I sympathize with the "prefix with underscore" idea for system users, but also: it's a bit too late for that I think, and not sure it's worth the trouble changing things towards that now (that said, in systemd-homed I opted to refuse allocating regular users with names starting with "_", to underline my sympathies — of course we also refuse regular users with names starting with "systemd-"). BTW, we changed Fedora (and ultimately RHEL) to now use the name "nobody" for the 65534 user, adjusting it more to match Debian. We don't use the same group name though (we generally follow the rule that user and group names match, and thus our group name for "nobody" is also "nobody". I think it would be great if Debian would agree ;-)) 4. Regarding DynamicUser= UID allocation: it's mostly OK if on some installations people allocated from the same range, as long as they didn't take the whole range. systemd always checks with NSS before using a UID from the range, to avoid conflicts. It does not assume exclusive ownership of the UID range assigned for the purpose, but of course it good in the long run to keep the ranges isolated to max out their use for each purpose. 5. I fear using only DynamicUser= for all new services is not going to work, even though I wished it worked. As soon as daemons need to write data persisently that shall be available even when they aren't running the short-lived UIDs are a problem. It works perfectly for daemons that do not leave state however. 6. In general I'd recommend to use the same UID ranges if at all possible, i.e. to avoid needless incompatibilites as much as possible. I mean, there might be reason to change the range but it better be a really really really good reason. i.e. a few statically, historically allocated UIDs from that range are not enough a reason I think. But of course you have to figure that out yourself. 7. When I picked the default range for the DynamicUser= stuff I actually had a look at Debian's range allocation and opted for a range that was the least scary looking and also worked on other distros somewhat reasonably, in particular to allow distros to just share the UID range if at all possible. I wish picking the range like that was not an excercise in vain? :-( 8. Fedora doesn't do static UID allocations anymore for static system users. Maybe Debian can decide the same and thus allow qmail/netplan/… or what is currently allocating from that range to just pick a differnt UID from any range? that would mean DynamicUser= and qmail/netplan/… to coexist pretty nicely since both would implement a similar algorithm of "try & fall back". Static UID allocations in the year 2020 are a bit backwards anyway, isn't it? 9. If you decide to use a different range for dynamic users than our upstream defaults, then of course it would be great to make it at least a subset instead of picking a non-overlapping range. 10. The smaller the UID range for dynamic users the more likely the chance of uid collisions during the allocation of a UID for a username. systemd starts with a UID hashed from the desired user name, but if that UID is already taken (which is likely given the ~4000 UIDs available is a small space) we pick random ones, but give up eventually if we keep hitting already used UIDs. I picked a high value of iterations before giving up (100 iterations before we give up), because the range is so small. If you halve it again, collisions are of course even more likely. A *lot* more likely (birthday paradox…). The question you have to ask yourself is how many concurrent DynamicUser=1 services do you intend to support before we do EBUSY because we can't allocate a user anymore? I figured 4K is a must... But it's of course up for you to figure out. Anyway, just a couple of thoughts off the top of my head, glancing on the discussions. Lennart -- Lennart Poettering, Berlin
