On Tue, 25 Oct 2016 at 10:31:00 +0300, Dmitry Bogatov wrote: > It may be worth to mention my dh-sysuser debhelper here: ... > * unless another package requires same users, they are > removed on package purge > * if possible, ensures, that install-purge-install cycle saves > numeric identifier of users
The Policy bug report about deletion of users <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833> seems to show consensus that packages should lock the accounts of system users corresponding to removed packages, but should never delete them. Is there a reason why the same rationale doesn't apply to dh-sysuser? If not, please change dh-sysuser to lock accounts on removal, and unlock on installation. The rationale given for never deleting these accounts automatically is that, in the presence of removable media, you can never know that you have deleted every file that is owned by the to-be-removed uid; but if any files remain owned by that uid, and the same uid is later reused for a different system user, then the new system user has been granted unintended privileges which could be a security vulnerability. (Unfortunately, the Policy bug does not seem to have reached consensus on which package(s) should be changed, in which ways, to make correct user handling straightforward.) I suspect that dh-sysuser could also benefit from review by an adduser maintainer. dh-sysuser does have the typical disadvantage of debhelper-generated maintainer scripts: whenever a bug is fixed in dh-sysuser, packages that use it don't get that bug fixed until they are rebuilt (effectively the same issue as static linking). Minimizing the amount of logic in the actual maintainer script (ideally reduced to just running one helper tool with appropriate arguments), and adding a dependency on the helper tool that has the actual logic, would mitigate this: perhaps that tool could live in the adduser package? I've wondered in the past whether systemd's sysusers.d(5) format would be a good basis for declarative or closer-to-declarative user creation in Debian. Like tmpfiles.d, there's nothing in that format that requires systemd, and it would seem a shame for Debian to invent its own wheel for this (even if a non-Linux-specific reimplementation of systemd-sysusers is needed, there's no reason it couldn't use sysusers.d(5) format). S
