Hi, Here's a reiteration (or well, rewrite) of mjo's earlier work [1]. I've made it into more GLEP-ish form, removed inline code samples which belong in implementation part and did some changes.
The main change from the earlier proposal is that we are extremely careful not to break stuff. Packages only create users/groups if they don't exist, they do not modify existing accounts. Users and groups are not removed at all. The text included below. [1] https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_packages --- GLEP: 9999 Title: User and group management via dedicated packages Author: Michał Górny <mgo...@gentoo.org>, Michael Orlitzky <m...@gentoo.org> Type: Standards Track Status: Draft Version: 1 Created: 2019-05-29 Last-Modified: 2019-05-29 Post-History: Content-Type: text/x-rst Requires: Replaces: 27 --- Abstract ======== A new approach for user/group management is proposed. Regular packages in dedicated categories are used to represent and create user and group accounts. Dependencies are used to request users and group from within regular packages, and to track their usage. Motivation ========== User management in Gentoo is currently ad-hoc. Users and groups are created through calling system tools directly in packages needing them. There is no systematic way of tracking which packages need specific users or groups, and determining which ones are obsolete. Coordinating properties of users and groups used by multiple packages must be done manually by developers. GLEP 27 originally attempted to address the problem. Posted in 2004, it never had reached the reference implementation state, and became obsolete. [#GLEP27]_ A good system user and group management proposal should address: 1. Tracking usage of users and groups, and determining which ones are obsolete. 2. Sharing users and groups reliably between different packages. 3. Maintaining fixed UIDs/GIDs that are consistent between different systems. 4. Providing local overrides for user/group properties. 5. Ensuring that users and groups are not created unnecessarily at build time. At the same time, the proposal should avoid unnecessary complexity to avoid sharing the fate of GLEP 27. This proposal aims to address those points without requiring a new EAPI or any changes in the package manager. Specification ============= Logical structure ----------------- In this proposal, system users and groups are represented by regular packages. Those packages logically represent the ownership of the respective users and group, and technically implement their creation. User packages are placed in ``user`` category. Each user package defines the properties of the particular user, and should be named after the user it creates. It must depend at build and run time on the groups user belongs to. Group packages are placed in ``group`` category. Each group package defines the properties of the particular group, and should be named after the group it creates. All user and group packages must define preferred fixed UIDs/GIDs, and they must be unique within the repository. The packages should indicate whether the value needs to be strictly enforced, or whether another UID/GID can be used when the user exists already or requested UID/GID is taken. Packages needing a specific user or group use dependencies to pull the required user/group packages. If the user is needed at build time, a build time dependency (``DEPEND``) must be used. If the user is needed at install time, a run time dependency (``RDEPEND``) must be used. If the user is only needed after the package is installed, ``PDEPEND`` must be used. Maintaining users/groups ------------------------ The primary technical function of user and group packages is to create the users and groups. This is done via invoking the respective system tools at ``pkg_preinst`` phase. This is done only if the user/group does not exist on the system already. Normally, the packages should not modify existing users, to preserve local modifications. If such a modification is necessary, the package should verify the existing values of changed properties, and update them only if they match the previous value. The package must not remove users/groups. Any cleanup actions must be done with explicit user approval, and therefore should be addressed by separate tooling. Home directory ownership ------------------------ If the user in question uses a regular home directory (i.e. not ``/dev/null``), the user package should maintain the directory via ``keepdir`` command. This allows for clean removal of the home directory if it is no longer needed. The package manager will also apply correct permissions if the directory does not exist yet. Note that since the user is not created until ``pkg_preinst``, the permissions to home directory should not be applied earlier than that. User/group name/identifier collision detection ---------------------------------------------- The user/group packages can install additional files in subdirectories of ``/var/lib`` indicating their respective names and identifiers. This ensures that if two packages ever happen to collide, the package manager's collision detection mechanism will trigger. Rationale ========= Satisfied goals --------------- Tracking of user/group usage is done through dependencies. As long as any installed package depends on a specific user/group package, the respective user/group is assumed to be used. If no package requiring the specific user/group is left, the package manager automatically prunes the package clearly indicating it is no longer used. Each user and group has a single respective package creating it. If multiple packages need it, they depend on the same package. This ensures that all properties are kept in a single location, and do not need to be synced. Having a single location with all predefined user/group ranges makes it possible to maintain fixed UID/GID definitions. This GLEP makes allocating them obligatory, and provides for detecting collisions. While this isn't enforced for existing users, it provides a way forward for new installations. Local overrides can be trivially implemented via local repository, through overriding the respective user/group ebuilds. The proposal also respects direct sysadmin modifications. Avoiding unnecessary user/group creation at build time is implemented via correct dependency types. While this was possible with the status quo, the dependency model should be more natural to developers and cause less mistakes. Category names -------------- The original proposal used ``sys-user`` and ``sys-group`` as category names. This was changed in order to avoid mixing them with regular packages in ``sys-*`` categories. The new names intentionally are single component to distinguish them from regular packages. Naming rules ------------ It has been pointed out that the package naming rules are more restrictive than user/group naming rules. This is why the proposal allows for package names to be different from user/group names. However, this is strongly discouraged and should only be used when really necessary. User/group updates ------------------ If sysadmin needs to change the properties (e.g. home directory) of some user/group, the obvious course of action is to modify the system databases directly. The GLEP aims to respect that and disallow altering existing user/groups unconditionally. If any updates need to be done, the packages need to verify previous values first. User/group removal ------------------ The original proposal attempted to remove user/groups automatically when the respective package was unmerged. This required verifying that no files are owned by the user/group in question which was both expensive in terms of I/O, and fragile. This GLEP follows the best practice of leaving obsolete user/groups accounts intact. This guarantees that no files with stale ownership are left (e.g. on unmounted filesystems) and that the same UID/GID is not reused for another user/group. Backwards Compatibility ======================= This GLEP preserves backwards compatibility with the existing method of user/group management. Both methods can coexist as long as necessary for the transition period, and the same user/group can be governed by both in parallel. However, some of the advantages will only be reliable once the old method is phased out, and only on new installations. This particularly applies to fixed UIDs/GIDs. Reference Implementation ======================== TODO References ========== .. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs (https://www.gentoo.org/glep/glep-0027.html) Copyright ========= This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
