Package: debian-policy Version: 4.6.0.1 Severity: wishlist Hi!
Currently, Policy does contain guidelines about system accounts being created on package installation. It is, however, more reluctant to give advice about accout deletion on package uninstall and/or purge. In Addition, the existing advice is somewhat hidden in chapter 9.2.2 documetning UID and GID classes. There is the requirement that a purged package vanishes completly. There seems to be consensus about this being not a good idea regarding account deletion since noone knows whether the local admin has given some files to the package account which would be left around unowned (and could even suddenly belong to a new account that was creatd with the same UID). There are way over 514 packages matching "adduser.*--system" on codesearch.debian.net, but just 125 packages containing "deluser.*--system". I didn't check in all details whether all of those matches are in maintainer scripts, but I think that this gives a rough overview how many packages do not delete their account at the current time. How about putting advice like this in policy: Suggestion 1: Create a dedicated chapter (which would ideally be placed between the current chapters 9.2.1. Introduction and 9.2.2. UID and GID classes) named "dynamically allocated system users or groups for packages" with the following contents: - packages can create users and groups on installation - usernames should be chosen wisely, allowing to deduce the related package from the name, and prefixed with an underscore - adduser --system is the preferred method to create package account, it takes responsibility of being policy compliant. Other packages doing this job might exist (dh-sysuser, for example). Suggestion 2a: Document that a package should not delete its user on uninstallation and/or purge. This reflects current practice of most packages but might need changes in some packages that currently delete their user. Those packages are the reason that this policy item should not be introduced as a MUST. Suggestion 2b: Document that a package may lock its user on uninstall, but leave it on the system on purge. That way, a leftover account could not be used as an attack vector and just blocks the uid/gid and the name. On reinstallation of a package, the existing, locked account would just be unlocked. This would be a new behavior that could be worth documenting in Policy. Should the policy editors indicate that this might be an option, adduser would be willing to implement a deluser --lock --system option that would lock a named account if its uid is in the appropriate range for system accounts, and adduser --system would not error out if the account already exists and would just remove the lock. Thus implementing this option in a package would just mean to add the appropriat deluser call to postrm uninstall while postinst can remain unchanged. transparency advice: I am on the adduser maintainer team and have the longest track history of caring for adduser of all active team members. I am willing to suggest wording, but I am not a policy expert and wording would probably be better if an experienced policy editor would write the appropriate language. How would a new chapter be inserted in Policy without destroying existing references to chapter numbers? I would like to hear your opinion on that. Thanks for considering. Greetings Marc
