* [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages
@ 2019-06-05 9:18 Michał Górny
2019-06-05 16:15 ` Michael Orlitzky
0 siblings, 1 reply; 4+ messages in thread
From: Michał Górny @ 2019-06-05 9:18 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Here's the updated GLEP text. It has a few small changes based
on feedback, and links reference implementation submitted to the ml.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
glep-9999.rst | 233 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 233 insertions(+)
create mode 100644 glep-9999.rst
diff --git a/glep-9999.rst b/glep-9999.rst
new file mode 100644
index 0000000..19555a6
--- /dev/null
+++ b/glep-9999.rst
@@ -0,0 +1,233 @@
+---
+GLEP: 9999
+Title: User and group management via dedicated packages
+Author: Michał Górny <mgorny@gentoo.org>,
+ Michael Orlitzky <mjo@gentoo.org>
+Type: Standards Track
+Status: Draft
+Version: 1
+Created: 2019-05-29
+Last-Modified: 2019-06-05
+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
+=============
+
+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 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, in order not
+to overwrite local modifications. If an explicit update is necessary,
+the package should compare the existing values against expected previous
+properties, and update them only if they were not changed.
+
+The package must not remove users/groups. When the account is no longer
+needed, the tooling must ensure that it is locked from access. However,
+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.
+
+
+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. 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.
+
+
+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 without explicit user request. 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 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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages
2019-06-05 9:18 [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages Michał Górny
@ 2019-06-05 16:15 ` Michael Orlitzky
2019-06-05 16:29 ` Michał Górny
2019-06-05 16:43 ` Ulrich Mueller
0 siblings, 2 replies; 4+ messages in thread
From: Michael Orlitzky @ 2019-06-05 16:15 UTC (permalink / raw
To: gentoo-dev
Should we require a mailing list review for new user/group packages?
It's difficult to modify a user once you've settled on a UID, home
directory, and shell; so it pays to get things right the first time.
The need is more apparent with fixed UIDs: if a popular package "steals"
a UID that some other package needs, then that other package is going to
be difficult or impossible to install (especially if it ultimately
depends on the popular package).
A mailing list review could elicit a "hey, my package NEEDS that UID,
and yours doesn't care" before it's too late.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages
2019-06-05 16:15 ` Michael Orlitzky
@ 2019-06-05 16:29 ` Michał Górny
2019-06-05 16:43 ` Ulrich Mueller
1 sibling, 0 replies; 4+ messages in thread
From: Michał Górny @ 2019-06-05 16:29 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Wed, 2019-06-05 at 12:15 -0400, Michael Orlitzky wrote:
> Should we require a mailing list review for new user/group packages?
>
> It's difficult to modify a user once you've settled on a UID, home
> directory, and shell; so it pays to get things right the first time.
Sounds like a good idea. I'll keep in mind for the next iteration
of this GLEP.
> The need is more apparent with fixed UIDs: if a popular package "steals"
> a UID that some other package needs, then that other package is going to
> be difficult or impossible to install (especially if it ultimately
> depends on the popular package).
>
> A mailing list review could elicit a "hey, my package NEEDS that UID,
> and yours doesn't care" before it's too late.
I've already seen a major issue today: we have multiple packages using
'git' user and requiring different setup for it (e.g. home directory).
This is already a big problem, and having proper review should decrease
the chance of things like this happening again.
And yes, we will need to figure out a good solution once we start
porting users.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages
2019-06-05 16:15 ` Michael Orlitzky
2019-06-05 16:29 ` Michał Górny
@ 2019-06-05 16:43 ` Ulrich Mueller
1 sibling, 0 replies; 4+ messages in thread
From: Ulrich Mueller @ 2019-06-05 16:43 UTC (permalink / raw
To: Michael Orlitzky; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
>>>>> On Wed, 05 Jun 2019, Michael Orlitzky wrote:
> Should we require a mailing list review for new user/group packages?
> It's difficult to modify a user once you've settled on a UID, home
> directory, and shell; so it pays to get things right the first time.
> The need is more apparent with fixed UIDs: if a popular package "steals"
> a UID that some other package needs, then that other package is going to
> be difficult or impossible to install (especially if it ultimately
> depends on the popular package).
> A mailing list review could elicit a "hey, my package NEEDS that UID,
> and yours doesn't care" before it's too late.
Policy requires such a review since a long time, at least for hardcoded
user and group IDs:
https://devmanual.gentoo.org/ebuild-writing/users-and-groups/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-06-05 16:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-05 9:18 [gentoo-dev] [PATCH v2] glep-xxxx: User and group management via dedicated packages Michał Górny
2019-06-05 16:15 ` Michael Orlitzky
2019-06-05 16:29 ` Michał Górny
2019-06-05 16:43 ` Ulrich Mueller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox