Bug#1006912: is it time to have account deletion in policy?
On Sun, Mar 13, 2022 at 03:03:34PM -0700, Sean Whitton wrote: > On Sat 12 Mar 2022 at 03:01PM +01, Marc Haber wrote: > > On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: > >> Roland Clobus has put a lot of work & thoughts into reproducible images, > >> so I've > >> added him to cc: now, so he can comment on this aspect of #1006912. > > > > Policy editors, I think we can now choose between taking care of the > > needs of reproducible images right with this policy change or do > > de-scope this temporarily until we have settled on the new wording > > (which also includes some definitions) and then handle this in a second > > change. I think the second change also needs the base-passwd people in > > the loop. > > The latter, please, assuming I'm not misunderstanding and the first > change makes things worse on the reproducibility front. I am not a native speaker, but in my understanding my proposed wording does not change the way we're creating UIDs right now, just clarified terminology and explicitly writes down how things are done now, and Roland confirmed that the current image process doesn't care about numerican UIDs at all since they already make sure that package installation happens in a pre-defined order. That being said, an upcoming adduser change will allow local administrators (including image creators) to pre-define the numerical UIDs before the actual account gets created. This, however, does not influence the order of accounts listed in /etc/passwd, for this to be reproducible, the passwd / shadow package should make sure that their user database files are sorted. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
Hello, On Sat 12 Mar 2022 at 03:01PM +01, Marc Haber wrote: > On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: >> Roland Clobus has put a lot of work & thoughts into reproducible images, so >> I've >> added him to cc: now, so he can comment on this aspect of #1006912. > > Policy editors, I think we can now choose between taking care of the > needs of reproducible images right with this policy change or do > de-scope this temporarily until we have settled on the new wording > (which also includes some definitions) and then handle this in a second > change. I think the second change also needs the base-passwd people in > the loop. The latter, please, assuming I'm not misunderstanding and the first change makes things worse on the reproducibility front. -- Sean Whitton signature.asc Description: PGP signature
Bug#1006912: is it time to have account deletion in policy?
On 12/03/2022 14:00, Holger Levsen wrote: On Sat, Mar 12, 2022 at 01:21:24PM +0100, Marc Haber wrote: Or would it be enough for reproducible images if adduser would finally implement #243929, making it possible to pre-determine UIDs before an image is built? for reproducible images it would be 'enough' but I believe this would also shift the burden of the work to each and every image designer, so in a way this feels like a workaround with the main purpose of removing load from base-passwd maintenance while putting load on everyone else forever :/ Roland Clobus has put a lot of work & thoughts into reproducible images, so I've added him to cc: now, so he can comment on this aspect of #1006912. I've read #243929 and #1006912. For reproducible images (based on live-build) the order of the creation of each user is determined by the order in which the packages are installed. When the image is built, it starts with the default user list, which is then expanded by the packages as they are installed. When, while (re-)generating an image, an account is deleted, it will also be in a deterministic order. So from the viewpoint of reproducible images, it does not matter in which order the lines in /etc/passwd are, nor whether the same UID number is assigned to a username. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1006912: is it time to have account deletion in policy?
On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: > Roland Clobus has put a lot of work & thoughts into reproducible images, so > I've > added him to cc: now, so he can comment on this aspect of #1006912. Policy editors, I think we can now choose between taking care of the needs of reproducible images right with this policy change or do de-scope this temporarily until we have settled on the new wording (which also includes some definitions) and then handle this in a second change. I think the second change also needs the base-passwd people in the loop. How would you prefer to do this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
On Sat, Mar 12, 2022 at 01:21:24PM +0100, Marc Haber wrote: > > unpredictable or non-deterministic allocation of such ids is a cause of non- > > reproducibiliy for Debian images and installations, so us reproducible folks > > would like to see "sensible" to be expanded to take reproducible builds into > > account. > So we should go (in Policy) more towards "dynamic global UIDs and GIDs > which may post additional load towards the base-passwd maintainers? I guess so, yes. :/ > Or would it be enough for reproducible images if adduser would finally > implement #243929, making it possible to pre-determine UIDs before an > image is built? for reproducible images it would be 'enough' but I believe this would also shift the burden of the work to each and every image designer, so in a way this feels like a workaround with the main purpose of removing load from base-passwd maintenance while putting load on everyone else forever :/ Roland Clobus has put a lot of work & thoughts into reproducible images, so I've added him to cc: now, so he can comment on this aspect of #1006912. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Smart things make us dumb. signature.asc Description: PGP signature
Bug#1006912: is it time to have account deletion in policy?
On Sat, Mar 12, 2022 at 11:58:31AM +, Holger Levsen wrote: > On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote: > > This is my patch. > > I like your patch. :) I just have one comment: > > > +``Dynamic local`` allocated ids should by default be arranged in some > > +sensible order, but the behavior should be configurable. > > unpredictable or non-deterministic allocation of such ids is a cause of non- > reproducibiliy for Debian images and installations, so us reproducible folks > would like to see "sensible" to be expanded to take reproducible builds into > account. So we should go (in Policy) more towards "dynamic global UIDs and GIDs which may post additional load towards the base-passwd maintainers? Or would it be enough for reproducible images if adduser would finally implement #243929, making it possible to pre-determine UIDs before an image is built? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
Hi Marc, On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote: > This is my patch. I like your patch. :) I just have one comment: > +``Dynamic local`` allocated ids should by default be arranged in some > +sensible order, but the behavior should be configurable. unpredictable or non-deterministic allocation of such ids is a cause of non- reproducibiliy for Debian images and installations, so us reproducible folks would like to see "sensible" to be expanded to take reproducible builds into account. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ „Ich dachte immer, jeder sei gegen den Krieg, bis ich herausfand, dass es welche gibt, die nicht hingehen müssen.“ (Erich Maria Remarque) signature.asc Description: PGP signature
Bug#1006912: is it time to have account deletion in policy?
On Tue, Mar 08, 2022 at 05:01:00PM -0700, Sean Whitton wrote: > 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. This is my patch. I took care to not change policy chapter numbers, especially 9.2.2 has remained 9.2.2. 9.2.1 has grown two subchapters. diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 83b71b1..46f4441 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -214,30 +214,92 @@ Users and groups .. _s9.2.1: -Introduction - +Packages and user and group accounts + + +Packages may use their own user ids (UIDs) and group ids (GIDs). The +recommended way to create those is using the ``adduser --system`` and +``addgroup --system`` programs in pre- or postinst. This does not require any +coordination and can simply be done. The numerical UIDs and GIDs of those +accounts will be different on every system (``dynamic local``). Packages +using this mechanism must be prepared to handle this. The most important +restriction is that such a package cannot ship files belonging to the package +account in the package, but need to chown those files to the new UID/GID +in postinst after they were created. + +``adduser --system`` and ``addgroup --system`` take care of creating a new +user in a policy compliant way with UID and GID chosen from the correct +numerical range. Packages should not wrap their calls around ``adduser`` and +``addgroup`` in any checks other than a check whether the executables exist +since both tools do some plausibility and policy compliance checks if the UID +or GID already exists. ``adduser``'s and ``delusers``'s output should not be +redirected. + +Packages can choose to create their UIDs and GIDs using any other method. +Packages other than ``base-passwd`` must not modify ``/etc/passwd``, +``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``. -The Debian system can be configured to use either plain or shadow -passwords. +The term ``system account`` or ``system user`` is used in this document (and +the ``adduser`` package) with the meaning that such an account is created and +used by Debian packages. Other documents might use these terms to refer to +any account that is defined in the ``system`` user database ``/etc/passwd``. Some user ids (UIDs) and group ids (GIDs) are reserved globally for use by certain packages. Because some packages need to include files which are owned by these users or groups, or need the ids compiled into binaries, these ids must be used on any Debian system only for the -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. 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. +purpose for which they are allocated. This is a serious restriction. -Packages other than ``base-passwd`` must not modify ``/etc/passwd``, -``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``. +Debian distinguishes between ``dynamic global`` UIDs and GIDs which just have +their numeric values globally allocated (the registry being +/usr/share/doc/base-passwd/README), and ``static global`` UIDs and GIDs which +are put by the ``base-passwd`` package into the password and group files of +every Debian system. + +UIDs and GIDs from the two ``global`` ranges must not be used without first +requesting an allocation from base-pas...@packages.debian.org and waiting for +confirmation that the allocation has been granted. + +By allocating UIDs and GIDs this way, Debian tries to avoid getting in the +way of local administration policies. In particular, many sites allocate +users and/or local system groups starting at 100. + +``Dynamic local`` allocated ids should by default be arranged in some +sensible order, but the behavior should be configurable. + +When maintainers choose a new hardcoded or dynamically generated user or +group name for packages to use, they should start those names with an +underscore. This minimizes collisions with locally created user accounts. If +possible, the user or group name should allow to deduce easily which package +the UID or GID belongs to. + +.. _s9.2.1.1: + +Account databases and password storage +~~ + +The Debian system can be configured to use either plain or shadow passwords. + +// elaborate on password encryption, locked passwords and locked accounts +// here? + +.. _s9.2.1.2: + +Locking package UIDs on
Bug#1006912: is it time to have account deletion in policy?
On Wed, Mar 09, 2022 at 11:07:54PM +0500, Andrey Rahmatullin wrote: > Previous, still open, bug from 2004: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692 thanks for pointing this out. I have made some notes (both for adduser and for policy) from that bug. Adduser development has regaind momentum, so I see it possible that we get the necessary adduser changes in Debian before bookworm so that we can, as a second step, amend policy and debhelper. Please expect me to come up with suggested wording for policy that referes to some adduser features that do not yet exist, but with my adduser hat on, I will do my best to have those features implemented before the suggested wording can be included in Policy. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
Previous, still open, bug from 2004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692 -- WBR, wRAR signature.asc Description: PGP signature
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
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
