Re: Guidance on solving the username namespacing problem
On Di, 14.01.20 15:55, Michael Biebl (biebl@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
Reply to: