Guidance on solving the username namespacing problem

[Russ Allbery]

Philipp Kern <pkern at debian.org> writes:

> I fear that we might need a local policy hook for migrations. If we end
> up renaming users that are actively referenced elsewhere, there might be
> cleanup tasks that need to be performed in lockstep.

> At the same time I'd strongly suggest that we do not go the way of
> distinguishing between the old user already being present on a machine
> and a new package install. That's a divergence that becomes actively
> harmful when you try to manage a set of machines.

Right, I think we should start by saying that all packages that already
create a user can keep using the user they are currently using for now,
and stop the bleeding by setting a requirement on newly-created users
going forward.

Then we can separately figure out what to do about the transition, if
anything.

> As I see it it isn't even guaranteed that services will have a dash,
> which is quite unfortunate. That would already make them way less likely
> to collide. Presumably we would not want to draw a distinction between
> "contains a dash and thus does not need an underscore" and "needs an
> underscore prefix to disambiguate", even though that would feel like an
> easier sell as it would be a behavior change for likely significantly
> less services. :/

I think starting everything with an underscore is best.  Talking systemd
upstream into using the underscore prefix seems like the best of all
worlds to me, if they'll go for it.

> Patching for Debian-specific behavior seems to be against the spirit of
> cross-distro reusability. So that question should be posed to systemd
> upstream and then we should decide based on the response?

That sounds right to me.

> It looks like the range must be contiguous, as it is compiled in[1].
> What are the preexisting ones apart from netplan that you have in mind?
> It feels like systemd's boundaries are pretty arbitrary (0xEF00 to
> 0xFFEF) but at the same time we might want to reserve a range for it in
> policy - given that right now it is effectively squatting in that range?

Yes.  We should also coordinate this with Colin as the base-passwd
maintainer.  Let me cc him explicitly.

It's possible that we can just use the existing systemd range, provided
that we can find some workable approach for netplan.

>> This should probably go somewhere near §9.2.2 "UID and GID classes":
>> it applies to future allocations in the 100-999 and 60000-64999 ranges,
>> and maybe to future allocations in the 0-99 range (although I don't
>> think we should be migrating existing low-uid hard-coded names like
>> games and proxy to _games and _proxy).

> That sounds fine to me too, although I wonder about placement. You are
> right that it's technically about the system-assigned ranges. At the
> same time it's also somewhat of a principle that might go into §9.2.1,
> as that already talks about the importance of UID allocation wrt local
> administration policies.

9.2.1 feels like the right spot to me.  I think that's close to 9.2.2.  We
could also reiterate that guidance in 9.2.2.

>> --- a/policy/ch-opersys.rst
>> +++ b/policy/ch-opersys.rst
>> @@ -228,13 +228,16 @@ purpose for which they are allocated. This is a serious restriction, and
>>  we should avoid getting in the way of local administration policies. In
>>  particular, many sites allocate users and/or local system groups
>>  starting at 100.
>> 
>>  Apart from this we should have dynamically allocated ids, which should
>>  by default be arranged in some sensible order, but the behavior should
>> -be configurable.
>> +be configurable. When maintainers choose a new hardcoded or dynamically
>> +generated username for packages to use, they should start this username
>> +with an underscore. This minimizes collisions with locally created user
>> +accounts.
>> 
>>  Packages other than ``base-passwd`` must not modify ``/etc/passwd``,
>>  ``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``.
>> 
>>  .. _s9.2.2:

This part looks good to me.

>> @@ -256,13 +259,14 @@ The UID and GID numbers are divided into classes as follows:
>>  100-999:
>>      Dynamically allocated system users and groups. Packages which need a
>>      user or group, but can have this user or group allocated dynamically
>>      and differently on each system, should use ``adduser --system`` to
>>      create the group and/or user. ``adduser`` will check for the
>>      existence of the user or group, and if necessary choose an unused id
>> -    based on the ranges specified in ``adduser.conf``.
>> +    based on the ranges specified in ``adduser.conf``. Usernames in this
>> +    range should be prefixed with an underscore.

I think this is too strong, since it implies that all packages that
already create users should change, and I don't think we've thought
through the implications of that yet.

-- 
Russ Allbery (rra at debian.org)              <https://www.eyrie.org/~eagle/>