Adding Colin as base-passwd maintainer. Sean Whitton <spwhit...@spwhitton.name> writes: > On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:
>> Currently, DynamicUser gets a uid from within the following range: >> 61184 - 65519. Those values can be configured during build time via >> -Ddynamic-uid-min= and -Ddynamic-uid-max. Those two numbers are oddly specific. Is there some history behind those specific boundaries? >> The debian policy has a section about uids and gids: >> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes >> >> The overlapping ranges are: >> 60000-64999: >> Globally allocated by the Debian project, but only created on demand. >> The ids are allocated centrally and statically, but the actual accounts >> are only created on users’ systems on demand. >> >> These ids are for packages which are obscure or which require many >> statically-allocated ids. These packages should check for and create the >> accounts in /etc/passwd or /etc/group (using adduser if it has this >> facility) if necessary. Packages which are likely to require further >> allocations should have a “hole” left after them in the allocation, to >> give them room to grow. We have needed very few of these over the history of the project. The complete currently-allocated list from base-passwd is: Reserved uids: uid | name | description ------+-------------------+--------------- 63434 | netplan | netplan 64000 | ftn | fidogate 64001 | mysql | mysql-server 64005 | tac-plus | tac-plus user 64010 | alias | qmail alias 64011 | qmaild | qmail daemon 64012 | qmails | qmail send 64013 | qmailr | qmail remove 64015 | qmailq | qmail queue 64016 | qmaill | qmail log 64017 | qmailp | qmail pw 64020 | asterisk | asterisk 64025 | vpopmail | vpopmail 64030 | slurm | slurm-llnl package 64035 | hacluster | heartbeat 64045 | ceph | ceph object storage 64050 | opensrf | Evergreen ILS 64055 | libvirt-qemu | libvirt guest migration support 64060 | nova | OpenStack Compute 64061 | cinder | OpenStack Block Storage 64062 | glance | OpenStack Image Given that, maybe a solution would be to reserve a range in this space for systemd dynamic users? >> 65000-65533: >> Reserved. >> >> We don't meet the requirement of the 60000-64999 range, which says that >> the ids need to be allocated statically (DynamicUser generated ids are >> ephemeral). The 65000-65533 range doesn't go into more detail, what >> purpose it is reserved. > I don't know why it's reserved either, but ISTM this is rather too small > a range for systemd's DynamicUser. Would you agree? I think this is reserved just because we've never had another use for it and were being conservative. >> There is also: >> 65536-4294967293: >> Dynamically allocated user accounts. By default adduser will not >> allocate UIDs and GIDs in this range, to ease compatibility with legacy >> systems where uid_t is still 16 bits. >> >> I'm not sure if it would be more suitable to pick the DynamicUser ids >> from this range. > This strikes me as suitable. We could either just change systemd's > configuration, or allocate a section of that range to systemd. We will definitely have conflicts with local allocations if we start using UIDs from this space. We theoretically say that this space is reserved, but Debian currently doesn't provide anywhere *close* to enough space for local UID allocation. Any site that needs more than 50,000 UIDs (which is extremely common) is almost certainly already using large chunks of this space. Both Stanford and Dropbox allocate UIDs from this space, for instance -- Dropbox because it was convenient to separate from human users, and Stanford because we couldn't create enough accounts for all of our users without using this space. This space is also often used for uidmap for containers. It's typical to have a single container user get a full 16-bit UID space that gets mapped to an equivalent range somewhere in the >2^16 space of the containing system. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>