1 |
Hi, |
2 |
|
3 |
Here's a reiteration (or well, rewrite) of mjo's earlier work [1]. I've |
4 |
made it into more GLEP-ish form, removed inline code samples which |
5 |
belong in implementation part and did some changes. |
6 |
|
7 |
The main change from the earlier proposal is that we are extremely |
8 |
careful not to break stuff. Packages only create users/groups if they |
9 |
don't exist, they do not modify existing accounts. Users and groups are |
10 |
not removed at all. The text included below. |
11 |
|
12 |
|
13 |
[1] https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_packages |
14 |
|
15 |
--- |
16 |
GLEP: 9999 |
17 |
Title: User and group management via dedicated packages |
18 |
Author: Michał Górny <mgorny@g.o>, |
19 |
Michael Orlitzky <mjo@g.o> |
20 |
Type: Standards Track |
21 |
Status: Draft |
22 |
Version: 1 |
23 |
Created: 2019-05-29 |
24 |
Last-Modified: 2019-05-29 |
25 |
Post-History: |
26 |
Content-Type: text/x-rst |
27 |
Requires: |
28 |
Replaces: 27 |
29 |
--- |
30 |
|
31 |
Abstract |
32 |
======== |
33 |
|
34 |
A new approach for user/group management is proposed. Regular packages |
35 |
in dedicated categories are used to represent and create user and group |
36 |
accounts. Dependencies are used to request users and group from within |
37 |
regular packages, and to track their usage. |
38 |
|
39 |
|
40 |
Motivation |
41 |
========== |
42 |
|
43 |
User management in Gentoo is currently ad-hoc. Users and groups are |
44 |
created through calling system tools directly in packages needing them. |
45 |
There is no systematic way of tracking which packages need specific |
46 |
users or groups, and determining which ones are obsolete. Coordinating |
47 |
properties of users and groups used by multiple packages must be done |
48 |
manually by developers. |
49 |
|
50 |
GLEP 27 originally attempted to address the problem. Posted in 2004, |
51 |
it never had reached the reference implementation state, and became |
52 |
obsolete. [#GLEP27]_ |
53 |
|
54 |
A good system user and group management proposal should address: |
55 |
|
56 |
1. Tracking usage of users and groups, and determining which ones |
57 |
are obsolete. |
58 |
|
59 |
2. Sharing users and groups reliably between different packages. |
60 |
|
61 |
3. Maintaining fixed UIDs/GIDs that are consistent between different |
62 |
systems. |
63 |
|
64 |
4. Providing local overrides for user/group properties. |
65 |
|
66 |
5. Ensuring that users and groups are not created unnecessarily |
67 |
at build time. |
68 |
|
69 |
At the same time, the proposal should avoid unnecessary complexity |
70 |
to avoid sharing the fate of GLEP 27. This proposal aims to address |
71 |
those points without requiring a new EAPI or any changes in the package |
72 |
manager. |
73 |
|
74 |
|
75 |
Specification |
76 |
============= |
77 |
|
78 |
Logical structure |
79 |
----------------- |
80 |
|
81 |
In this proposal, system users and groups are represented by regular |
82 |
packages. Those packages logically represent the ownership of |
83 |
the respective users and group, and technically implement their |
84 |
creation. |
85 |
|
86 |
User packages are placed in ``user`` category. Each user package |
87 |
defines the properties of the particular user, and should be named after |
88 |
the user it creates. It must depend at build and run time on the groups |
89 |
user belongs to. |
90 |
|
91 |
Group packages are placed in ``group`` category. Each group package |
92 |
defines the properties of the particular group, and should be named |
93 |
after the group it creates. |
94 |
|
95 |
All user and group packages must define preferred fixed UIDs/GIDs, |
96 |
and they must be unique within the repository. The packages should |
97 |
indicate whether the value needs to be strictly enforced, or whether |
98 |
another UID/GID can be used when the user exists already or requested |
99 |
UID/GID is taken. |
100 |
|
101 |
Packages needing a specific user or group use dependencies to pull |
102 |
the required user/group packages. If the user is needed at build time, |
103 |
a build time dependency (``DEPEND``) must be used. If the user is |
104 |
needed at install time, a run time dependency (``RDEPEND``) must be |
105 |
used. If the user is only needed after the package is installed, |
106 |
``PDEPEND`` must be used. |
107 |
|
108 |
|
109 |
Maintaining users/groups |
110 |
------------------------ |
111 |
|
112 |
The primary technical function of user and group packages is to create |
113 |
the users and groups. This is done via invoking the respective system |
114 |
tools at ``pkg_preinst`` phase. This is done only if the user/group |
115 |
does not exist on the system already. |
116 |
|
117 |
Normally, the packages should not modify existing users, to preserve |
118 |
local modifications. If such a modification is necessary, the package |
119 |
should verify the existing values of changed properties, and update |
120 |
them only if they match the previous value. |
121 |
|
122 |
The package must not remove users/groups. Any cleanup actions must |
123 |
be done with explicit user approval, and therefore should be addressed |
124 |
by separate tooling. |
125 |
|
126 |
|
127 |
Home directory ownership |
128 |
------------------------ |
129 |
|
130 |
If the user in question uses a regular home directory (i.e. not |
131 |
``/dev/null``), the user package should maintain the directory |
132 |
via ``keepdir`` command. This allows for clean removal of the home |
133 |
directory if it is no longer needed. The package manager will also |
134 |
apply correct permissions if the directory does not exist yet. |
135 |
|
136 |
Note that since the user is not created until ``pkg_preinst``, |
137 |
the permissions to home directory should not be applied earlier than |
138 |
that. |
139 |
|
140 |
|
141 |
User/group name/identifier collision detection |
142 |
---------------------------------------------- |
143 |
|
144 |
The user/group packages can install additional files in subdirectories |
145 |
of ``/var/lib`` indicating their respective names and identifiers. |
146 |
This ensures that if two packages ever happen to collide, the package |
147 |
manager's collision detection mechanism will trigger. |
148 |
|
149 |
|
150 |
Rationale |
151 |
========= |
152 |
|
153 |
Satisfied goals |
154 |
--------------- |
155 |
|
156 |
Tracking of user/group usage is done through dependencies. As long |
157 |
as any installed package depends on a specific user/group package, |
158 |
the respective user/group is assumed to be used. If no package |
159 |
requiring the specific user/group is left, the package manager |
160 |
automatically prunes the package clearly indicating it is no longer |
161 |
used. |
162 |
|
163 |
Each user and group has a single respective package creating it. |
164 |
If multiple packages need it, they depend on the same package. This |
165 |
ensures that all properties are kept in a single location, and do not |
166 |
need to be synced. |
167 |
|
168 |
Having a single location with all predefined user/group ranges makes it |
169 |
possible to maintain fixed UID/GID definitions. This GLEP makes |
170 |
allocating them obligatory, and provides for detecting collisions. |
171 |
While this isn't enforced for existing users, it provides a way forward |
172 |
for new installations. |
173 |
|
174 |
Local overrides can be trivially implemented via local repository, |
175 |
through overriding the respective user/group ebuilds. The proposal also |
176 |
respects direct sysadmin modifications. |
177 |
|
178 |
Avoiding unnecessary user/group creation at build time is implemented |
179 |
via correct dependency types. While this was possible with the status |
180 |
quo, the dependency model should be more natural to developers and cause |
181 |
less mistakes. |
182 |
|
183 |
|
184 |
Category names |
185 |
-------------- |
186 |
|
187 |
The original proposal used ``sys-user`` and ``sys-group`` as category |
188 |
names. This was changed in order to avoid mixing them with regular |
189 |
packages in ``sys-*`` categories. |
190 |
|
191 |
The new names intentionally are single component to distinguish them |
192 |
from regular packages. |
193 |
|
194 |
|
195 |
Naming rules |
196 |
------------ |
197 |
|
198 |
It has been pointed out that the package naming rules are more |
199 |
restrictive than user/group naming rules. This is why the proposal |
200 |
allows for package names to be different from user/group names. |
201 |
However, this is strongly discouraged and should only be used when |
202 |
really necessary. |
203 |
|
204 |
|
205 |
User/group updates |
206 |
------------------ |
207 |
|
208 |
If sysadmin needs to change the properties (e.g. home directory) of some |
209 |
user/group, the obvious course of action is to modify the system |
210 |
databases directly. The GLEP aims to respect that and disallow altering |
211 |
existing user/groups unconditionally. If any updates need to be done, |
212 |
the packages need to verify previous values first. |
213 |
|
214 |
|
215 |
User/group removal |
216 |
------------------ |
217 |
|
218 |
The original proposal attempted to remove user/groups automatically |
219 |
when the respective package was unmerged. This required verifying that |
220 |
no files are owned by the user/group in question which was both |
221 |
expensive in terms of I/O, and fragile. |
222 |
|
223 |
This GLEP follows the best practice of leaving obsolete user/groups |
224 |
accounts intact. This guarantees that no files with stale ownership are |
225 |
left (e.g. on unmounted filesystems) and that the same UID/GID is not |
226 |
reused for another user/group. |
227 |
|
228 |
|
229 |
Backwards Compatibility |
230 |
======================= |
231 |
|
232 |
This GLEP preserves backwards compatibility with the existing method |
233 |
of user/group management. Both methods can coexist as long as necessary |
234 |
for the transition period, and the same user/group can be governed |
235 |
by both in parallel. |
236 |
|
237 |
However, some of the advantages will only be reliable once the old |
238 |
method is phased out, and only on new installations. This particularly |
239 |
applies to fixed UIDs/GIDs. |
240 |
|
241 |
|
242 |
Reference Implementation |
243 |
======================== |
244 |
|
245 |
TODO |
246 |
|
247 |
|
248 |
References |
249 |
========== |
250 |
|
251 |
.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs |
252 |
(https://www.gentoo.org/glep/glep-0027.html) |
253 |
|
254 |
|
255 |
Copyright |
256 |
========= |
257 |
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
258 |
Unported License. To view a copy of this license, visit |
259 |
http://creativecommons.org/licenses/by-sa/3.0/. |
260 |
-- |
261 |
Best regards, |
262 |
Michał Górny |