summaryrefslogtreecommitdiff
blob: 6357d37a91bfb94b793cc035154ca9c403d26fe4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
---
GLEP: 81
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-18
Post-History: 2019-05-29
Content-Type: text/x-rst
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 RFCs 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 v4.  [#REFIMPL]_


References
==========

.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs
   (https://www.gentoo.org/glep/glep-0027.html)

.. [#REFIMPL] [gentoo-dev] [PATCH v4 0/9] User/group packages
   (https://archives.gentoo.org/gentoo-dev/message/527b343890c1280cb64efce2e941fdae)


Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License. To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/3.0/.