Philipp Kern <pk...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
