[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: