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-serverI'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