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