Bug#1006912: is it time to have account deletion in policy?
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
Reply to: