Guidance on solving the username namespacing problem

[Lennart Poettering]

On Di, 14.01.20 15:55, Michael Biebl (biebl at 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