Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Michael Biebl]

Am 15.09.18 um 20:31 schrieb Russ Allbery:
> Adding Colin as base-passwd maintainer.
> 
> Sean Whitton  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?

There is
http://0pointer.net/blog/dynamic-users-with-systemd.html

and

https://salsa.debian.org/systemd-team/systemd/blob/master/doc/UIDS-GIDS.md
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Russ Allbery]

Adding Colin as base-passwd maintainer.

Sean Whitton  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:
>> 6-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 6-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)   

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Simon McVittie]

On Sat, 15 Sep 2018 at 08:47:19 -0700, Sean Whitton wrote:
> On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:
> > 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.

Beware that if systemd dynamic users are above the 16-bit boundary, then
they won't work well with systemd-nspawn and other container systems that
give a 16-bit uid range to each container (mapping uids N+0 to N+65535
in the top-level uid namespace to uids 0 to 65535 in the container's
uid namespace, where N is large; so when systemd inside the container
thinks it's allocating uid 64923 to a service, it's really uid N+64923
in the top-level init namespace). That's a useful technique because
it assigns a unique uid to each process that ought to be protected from
other processes, which protects both the host system and other containers
from a compromised container.

smcv

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Sean Whitton]

[copying in debian-policy]

Hello,

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.
>
> 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:
> 6-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.
>
> 65000-65533:
>  Reserved.
>
> We don't meet the requirement of the 6-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?

> 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 probably don't need the legacy systems compatibility anymore.  So
maybe at some point adduser will start creating users in this range.  So
maybe we should carve out a section of that range for systemd, for
future proofing?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Michael Biebl]

Am 10.08.2018 um 08:23 schrieb Michael Biebl:
> CCing Sean to get his input as debian-policy maintainer.
> 
> Sean, you can get more in-detail documentation about DynamicUser at
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=

There is also
https://github.com/systemd/systemd/blob/master/doc/UIDS-GIDS.md
which I'd like to mention here.



signature.asc
Description: OpenPGP digital signature

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Helmut Grohne]

Hi Michael,

On Fri, Aug 10, 2018 at 08:23:38AM +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.
> 
> The debian policy has a section about uids and gids:
> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes

Thank you for thinking of this. Your attention to detail is much
appreciated. I also like your way of openly communicating problems by
filing bugs against your own packages.

> 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.

That's not exactly correct. While adduser will not pick from this range
for regular user ids, it will pick for "subuids" (see /etc/subuid and
man newuidmap). Doing so is necessary for practically using user
namespaces (a feature that is disabled in Debian kernels by default).

> I'm not sure if it would be more suitable to pick the DynamicUser ids
> from this range.

So I think the answer here is "no" as those allocations have happened on
user systems already.

As far as I can see, the only reasonable thing to do here is to allocate
a range specifically for systemd in the Debian policy.

> CCing Sean to get his input as debian-policy maintainer.

I actually propose that this bug is reassigned to debian-policy or that
a clone of this bug is assigned to debian-policy, because it will need
to change.

Helmut

Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

[Michael Biebl]

Package: systemd
Version: 239-7
Severity: important

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.

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:
6-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.

65000-65533:
 Reserved.

We don't meet the requirement of the 6-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.

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.

Filing this bug report so we don't forget about this.

CCing Sean to get his input as debian-policy maintainer.

Sean, you can get more in-detail documentation about DynamicUser at
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=

Regards,
Michael
-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13-8
ii  libaudit11:2.8.3-1+b1
ii  libblkid12.32-0.4
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.4-2
ii  libgcrypt20  1.8.3-1
ii  libgnutls30  3.5.19-1
ii  libgpg-error01.32-1
ii  libidn11 1.33-2.2
ii  libip4tc01.6.2-1.1
ii  libkmod2 25-1
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32-0.4
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-7
ii  mount2.32-0.4
ii  procps   2:3.3.15-2
ii  util-linux   2.32-0.4

Versions of packages systemd recommends:
ii  dbus1.12.10-1
ii  libpam-systemd  239-7

Versions of packages systemd suggests:
ii  policykit-10.105-21
ii  systemd-container  239-7

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 239-7

-- no debconf information