Guidance on solving the username namespacing problem
Philipp Kern
pkern at debian.org
Tue Jan 14 10:13:56 GMT 2020
On 2020-01-05 23:33, Philipp Kern wrote:
> 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.
So it looks like this is effectively groundhog day for them as Michael
pointed me to [1] where the same thing was discussed before.
Given the DynamicUser design[2] I'd still assume that where it is in the
UID space effectively does not matter much, it's fungible. There will be
effectively no files permanently owned by those UIDs because the
filesystem locations where the services can write are restricted and
tightly managed.
So dear systemd maintainers, how would you think about changing the UID
space to the above? 2249 UIDs vs. 4335 UIDs means that the space is
effectively halved, which might be concerning. It is unfortunate that
this cannot be changed at runtime, but if we get bug reports about this
I feel like it should be possible to make it take multiple ranges
instead. Apart from where the space needs to be located it does not seem
like there are strong reasons to prefer systemd's current range over any
other. I don't know what happens if that range is changed across a
package upgrade, though. Presumably the hashes would be different so
actually making the change might be tricky.
Kind regards and thanks
Philipp Kern
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905817
[2] http://0pointer.net/blog/dynamic-users-with-systemd.html
More information about the Pkg-systemd-maintainers
mailing list