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 package deinstallation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A package should lock its UIDs on uninstallation, but leave the UIDs and GIDs +in place on purge. The local administration might have used the UIDs and GIDs +for files that the package doesn't know of; removing the account would leave +those files ownerless and may expose information to unrelated parties in the +case that the numeric UIDs or GIDs get re-used at some later time. + +The ``deluser`` tool offers helpful functionality that allows a postrm script +to follow policy while giving the local administrator the possibility to +override policy so that package-related UIDs and GIDs are actually removed +from the system on purge. See the deluser manual package for details. + +// this is not yet implemented in deluser .. _s9.2.2: -- ----------------------------------------------------------------------------- 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
