Guidance on solving the username namespacing problem

Philipp Kern pkern at debian.org
Sun Jan 5 22:33:53 GMT 2020


Thanks again, Russ, Colin and Simon!

On 1/5/2020 7:25 PM, Russ Allbery wrote:
> 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.

Agreed. Re-reading it, it seems much too strong. Although I'm unsure how
to phrase it differently (see below). So the following has so far been
uncontroversial as a patch to policy:

> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -231,7 +231,10 @@ 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``.

I'd also propose the following hunk as I was myself confused where this
list was maintained - base-passwd is mentioned in 0-99 but not
explicitly in the on demand part. As policy seems to defer to that
package as the list, it would seem like policy should state this explicitly.

> @@ -268,8 +271,10 @@ The UID and GID numbers are divided into classes as follows:
> 
>  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.
> +    demand. The ids are allocated centrally, but the actual accounts are
> +    only created on users' systems on demand. Some of them are statically
> +    allocated. The authoritative allocation for this range is maintained
> +    in the ``base-passwd`` package.
> 
>      These ids are for packages which are obscure or which require many
>      statically-allocated ids. These packages should check for and create

Now there's the question if we need explicit guidance in the UID bit
about existing packages as well. How would the following sound instead
of my prior proposal?

> @@ -259,7 +262,9 @@ The UID and GID numbers are divided into classes as follows:
>      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``. New packages
> +    should follow the guidance of using an underscore prefix for their
> +    username.
> 
>  1000-59999:
>      Dynamically allocated user accounts. By default ``adduser`` will

And then the following (in spirit) to base-passwd to make the systemd
allocation explicit:

> --- a/README
> +++ b/README
> @@ -32,6 +32,9 @@ registry of allocations.
>  Reserved uids:
>      uid   | name              | description
>      ------+-------------------+---------------
> +    61184 |                   | reserved for systemd dynamic users
> +      -   |                   |
> +    63433 |                   |
>      63434 | netplan           | netplan
>      64000 | ftn               | fidogate
>      64001 | mysql             | mysql-server

I'd still like to hear from the systemd maintainers about their opinion
about the UID space shift and slight reduction, of course.

Kind regards and thanks
Philipp Kern



More information about the Pkg-systemd-maintainers mailing list