From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7217D138334 for ; Sun, 9 Jun 2019 11:40:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DC61CE08CE; Sun, 9 Jun 2019 11:40:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 69A09E08A6 for ; Sun, 9 Jun 2019 11:40:01 +0000 (UTC) Received: from localhost.localdomain (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id AC96E345AD8; Sun, 9 Jun 2019 11:39:59 +0000 (UTC) From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= Subject: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages Date: Sun, 9 Jun 2019 13:39:55 +0200 Message-Id: <20190609113955.19208-1-mgorny@gentoo.org> X-Mailer: git-send-email 2.22.0.rc3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: c2839e8a-3812-4d87-8eaf-b3ed8e753228 X-Archives-Hash: 2ca74142fa1d160f7573303d88b185b4 Changes in v3: - Added 'Policy' section. Notably, it deprecates the old method, requires RFC for new users/groups, and makes UID/GID assignment explicitly required. - Removed PDEPEND option in favor of RDEPEND. - Changed the behavior to explicitly update user/group properties on rebuild/upgrade. This is necessary to handle unlocking accounts and generally seems to make more sense. - Removed obsolete category section from rationale. -- Best regards, Michał Górny Signed-off-by: Michał Górny --- glep-0081.rst | 246 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 246 insertions(+) create mode 100644 glep-0081.rst diff --git a/glep-0081.rst b/glep-0081.rst new file mode 100644 index 0000000..5bfd048 --- /dev/null +++ b/glep-0081.rst @@ -0,0 +1,246 @@ +--- +GLEP: 81 +Title: User and group management via dedicated packages +Author: Michał Górny , + Michael Orlitzky +Type: Standards Track +Status: Draft +Version: 1 +Created: 2019-05-29 +Last-Modified: 2019-06-09 +Post-History: 2019-05-29 +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. + +6. Providing support for centralized account management (e.g. LDAP). + +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 +============= + +Policy +------ + +Following the acceptance of this GLEP, all new users and groups must +be created via user/group packages as defined in this GLEP. The old +method may still be used for existing users/groups, in existing +packages. + +All new users and groups must have unique UIDs/GIDs assigned +by developers. The developer adding them is responsible for checking +for collisions. + +Before adding a new user and/or group, the developer must send a RFC +to the ``gentoo-dev`` mailing list. + + +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 ``acct-user`` category. Each user package +defines the properties of the particular user, and must be named after +the user it creates. It must depend at build and run time on the groups +the user belongs to. + +Group packages are placed in ``acct-group`` category. Each group +package defines the properties of the particular group, and must 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 is acceptable 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 and/or run time, a run time dependency (``RDEPEND``) +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. + +If the user or group exists already, the package performs necessary +modifications in order to meet requested properties. This includes +updating user's home directory path (but not moving the directory +itself), shell and/or group membership. However, UID/GID is not +modified. + +The package must not remove users/groups. When the account is no longer +needed, the tooling must ensure that it is locked from access. +Appropriately, the packages must be able to reenable users when they +are installed again. + +Additional tools may be provided to help users remove groups and users. +However, such actions need to be explicitly confirmed by the system +administrator. + + +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. + + +Rationale +========= + +Requiring mailing list RFC +-------------------------- + +The policy explicitly requires RFC-es for new users and groups, as they +have global scopes and effects of mistakes while adding them are hard +to fix. Wider review should decrease the risk of major design mistakes. + +To provide one example, right now we have two different packages +creating ``git`` user and requiring a different home directory for +the user. As a result, the first package being installed defines +the actual home directory, and both technically can not be installed +at the same time. + + +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. 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. + + +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 while ensuring that they are locked out properly. 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 +======================== + +The reference implementation has been submitted to review on gentoo-dev +mailing list. The version at the time of writing is v2. [#REFIMPL]_ + + +References +========== + +.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs + (https://www.gentoo.org/glep/glep-0027.html) + +.. [#REFIMPL] [gentoo-dev] [PATCH v2 0/9] User/group packages + (https://archives.gentoo.org/gentoo-dev/message/ccc85af0511f70ee9d3549b89bd8a40b) + + +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/. -- 2.22.0.rc3