Re: Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy
Adding Colin as base-passwd maintainer.
Sean Whitton <spwhitton@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: