Bug#1006912: is it time to have account deletion in policy?
Hello Marc,
On Tue 08 Mar 2022 at 07:40am +01, Marc Haber wrote:
> 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
This sounds good, though we would need an extremely strong argument for
inserting rather than appending the new section -- we do not want to
renumber sections not just because it breaks hyperlinks, but because it
breaks purely textual references to Policy sections in bugs that remain
open, mailing list posts to which people still refer, etc.
> - 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).
It would be good to get some input from people who use other methods. I
would always look to adduser myself, but there might be others who feel
strongly that it's not right for certain classes of case -- perhaps we
want to limit the scope of this advice a bit.
> 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.
Sounds good.
> 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.
Sounds like a nice improvement on the current situation.
> 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?
Please go ahead and write a patch. The Policy Editors are happy to
review and edit proposed wording but we can't be responsible for
producing all of the text that gets added to Policy.
--
Sean Whitton
Reply to: