1 |
Changes in v3: |
2 |
|
3 |
- Added 'Policy' section. Notably, it deprecates the old method, |
4 |
requires RFC for new users/groups, and makes UID/GID assignment |
5 |
explicitly required. |
6 |
|
7 |
- Removed PDEPEND option in favor of RDEPEND. |
8 |
|
9 |
- Changed the behavior to explicitly update user/group properties |
10 |
on rebuild/upgrade. This is necessary to handle unlocking accounts |
11 |
and generally seems to make more sense. |
12 |
|
13 |
- Removed obsolete category section from rationale. |
14 |
|
15 |
-- |
16 |
Best regards, |
17 |
Michał Górny |
18 |
|
19 |
|
20 |
Signed-off-by: Michał Górny <mgorny@g.o> |
21 |
--- |
22 |
glep-0081.rst | 246 ++++++++++++++++++++++++++++++++++++++++++++++++++ |
23 |
1 file changed, 246 insertions(+) |
24 |
create mode 100644 glep-0081.rst |
25 |
|
26 |
diff --git a/glep-0081.rst b/glep-0081.rst |
27 |
new file mode 100644 |
28 |
index 0000000..5bfd048 |
29 |
--- /dev/null |
30 |
+++ b/glep-0081.rst |
31 |
@@ -0,0 +1,246 @@ |
32 |
+--- |
33 |
+GLEP: 81 |
34 |
+Title: User and group management via dedicated packages |
35 |
+Author: Michał Górny <mgorny@g.o>, |
36 |
+ Michael Orlitzky <mjo@g.o> |
37 |
+Type: Standards Track |
38 |
+Status: Draft |
39 |
+Version: 1 |
40 |
+Created: 2019-05-29 |
41 |
+Last-Modified: 2019-06-09 |
42 |
+Post-History: 2019-05-29 |
43 |
+Content-Type: text/x-rst |
44 |
+Requires: |
45 |
+Replaces: 27 |
46 |
+--- |
47 |
+ |
48 |
+Abstract |
49 |
+======== |
50 |
+ |
51 |
+A new approach for user/group management is proposed. Regular packages |
52 |
+in dedicated categories are used to represent and create user and group |
53 |
+accounts. Dependencies are used to request users and group from within |
54 |
+regular packages, and to track their usage. |
55 |
+ |
56 |
+ |
57 |
+Motivation |
58 |
+========== |
59 |
+ |
60 |
+User management in Gentoo is currently ad-hoc. Users and groups are |
61 |
+created through calling system tools directly in packages needing them. |
62 |
+There is no systematic way of tracking which packages need specific |
63 |
+users or groups, and determining which ones are obsolete. Coordinating |
64 |
+properties of users and groups used by multiple packages must be done |
65 |
+manually by developers. |
66 |
+ |
67 |
+GLEP 27 originally attempted to address the problem. Posted in 2004, |
68 |
+it never had reached the reference implementation state, and became |
69 |
+obsolete. [#GLEP27]_ |
70 |
+ |
71 |
+A good system user and group management proposal should address: |
72 |
+ |
73 |
+1. Tracking usage of users and groups, and determining which ones |
74 |
+ are obsolete. |
75 |
+ |
76 |
+2. Sharing users and groups reliably between different packages. |
77 |
+ |
78 |
+3. Maintaining fixed UIDs/GIDs that are consistent between different |
79 |
+ systems. |
80 |
+ |
81 |
+4. Providing local overrides for user/group properties. |
82 |
+ |
83 |
+5. Ensuring that users and groups are not created unnecessarily |
84 |
+ at build time. |
85 |
+ |
86 |
+6. Providing support for centralized account management (e.g. LDAP). |
87 |
+ |
88 |
+At the same time, the proposal should avoid unnecessary complexity |
89 |
+to avoid sharing the fate of GLEP 27. This proposal aims to address |
90 |
+those points without requiring a new EAPI or any changes in the package |
91 |
+manager. |
92 |
+ |
93 |
+ |
94 |
+Specification |
95 |
+============= |
96 |
+ |
97 |
+Policy |
98 |
+------ |
99 |
+ |
100 |
+Following the acceptance of this GLEP, all new users and groups must |
101 |
+be created via user/group packages as defined in this GLEP. The old |
102 |
+method may still be used for existing users/groups, in existing |
103 |
+packages. |
104 |
+ |
105 |
+All new users and groups must have unique UIDs/GIDs assigned |
106 |
+by developers. The developer adding them is responsible for checking |
107 |
+for collisions. |
108 |
+ |
109 |
+Before adding a new user and/or group, the developer must send a RFC |
110 |
+to the ``gentoo-dev`` mailing list. |
111 |
+ |
112 |
+ |
113 |
+Logical structure |
114 |
+----------------- |
115 |
+ |
116 |
+In this proposal, system users and groups are represented by regular |
117 |
+packages. Those packages logically represent the ownership of |
118 |
+the respective users and group, and technically implement their |
119 |
+creation. |
120 |
+ |
121 |
+User packages are placed in ``acct-user`` category. Each user package |
122 |
+defines the properties of the particular user, and must be named after |
123 |
+the user it creates. It must depend at build and run time on the groups |
124 |
+the user belongs to. |
125 |
+ |
126 |
+Group packages are placed in ``acct-group`` category. Each group |
127 |
+package defines the properties of the particular group, and must be |
128 |
+named after the group it creates. |
129 |
+ |
130 |
+All user and group packages must define preferred fixed UIDs/GIDs, |
131 |
+and they must be unique within the repository. The packages should |
132 |
+indicate whether the value needs to be strictly enforced, or whether |
133 |
+another UID/GID is acceptable when the user exists already or requested |
134 |
+UID/GID is taken. |
135 |
+ |
136 |
+Packages needing a specific user or group use dependencies to pull |
137 |
+the required user/group packages. If the user is needed at build time, |
138 |
+a build time dependency (``DEPEND``) must be used. If the user is |
139 |
+needed at install and/or run time, a run time dependency (``RDEPEND``) |
140 |
+must be used. |
141 |
+ |
142 |
+ |
143 |
+Maintaining users/groups |
144 |
+------------------------ |
145 |
+ |
146 |
+The primary technical function of user and group packages is to create |
147 |
+the users and groups. This is done via invoking the respective system |
148 |
+tools at ``pkg_preinst`` phase. This is done only if the user/group |
149 |
+does not exist on the system already. |
150 |
+ |
151 |
+If the user or group exists already, the package performs necessary |
152 |
+modifications in order to meet requested properties. This includes |
153 |
+updating user's home directory path (but not moving the directory |
154 |
+itself), shell and/or group membership. However, UID/GID is not |
155 |
+modified. |
156 |
+ |
157 |
+The package must not remove users/groups. When the account is no longer |
158 |
+needed, the tooling must ensure that it is locked from access. |
159 |
+Appropriately, the packages must be able to reenable users when they |
160 |
+are installed again. |
161 |
+ |
162 |
+Additional tools may be provided to help users remove groups and users. |
163 |
+However, such actions need to be explicitly confirmed by the system |
164 |
+administrator. |
165 |
+ |
166 |
+ |
167 |
+Home directory ownership |
168 |
+------------------------ |
169 |
+ |
170 |
+If the user in question uses a regular home directory (i.e. not |
171 |
+``/dev/null``), the user package should maintain the directory |
172 |
+via ``keepdir`` command. This allows for clean removal of the home |
173 |
+directory if it is no longer needed. The package manager will also |
174 |
+apply correct permissions if the directory does not exist yet. |
175 |
+ |
176 |
+Note that since the user is not created until ``pkg_preinst``, |
177 |
+the permissions to home directory should not be applied earlier than |
178 |
+that. |
179 |
+ |
180 |
+ |
181 |
+Rationale |
182 |
+========= |
183 |
+ |
184 |
+Requiring mailing list RFC |
185 |
+-------------------------- |
186 |
+ |
187 |
+The policy explicitly requires RFC-es for new users and groups, as they |
188 |
+have global scopes and effects of mistakes while adding them are hard |
189 |
+to fix. Wider review should decrease the risk of major design mistakes. |
190 |
+ |
191 |
+To provide one example, right now we have two different packages |
192 |
+creating ``git`` user and requiring a different home directory for |
193 |
+the user. As a result, the first package being installed defines |
194 |
+the actual home directory, and both technically can not be installed |
195 |
+at the same time. |
196 |
+ |
197 |
+ |
198 |
+Satisfied goals |
199 |
+--------------- |
200 |
+ |
201 |
+Tracking of user/group usage is done through dependencies. As long |
202 |
+as any installed package depends on a specific user/group package, |
203 |
+the respective user/group is assumed to be used. If no package |
204 |
+requiring the specific user/group is left, the package manager |
205 |
+automatically prunes the package clearly indicating it is no longer |
206 |
+used. |
207 |
+ |
208 |
+Each user and group has a single respective package creating it. |
209 |
+If multiple packages need it, they depend on the same package. This |
210 |
+ensures that all properties are kept in a single location, and do not |
211 |
+need to be synced. |
212 |
+ |
213 |
+Having a single location with all predefined user/group ranges makes it |
214 |
+possible to maintain fixed UID/GID definitions. This GLEP makes |
215 |
+allocating them obligatory. While this isn't enforced for existing |
216 |
+users, it provides a way forward for new installations. |
217 |
+ |
218 |
+Local overrides can be trivially implemented via local repository, |
219 |
+through overriding the respective user/group ebuilds. The proposal also |
220 |
+respects direct sysadmin modifications. |
221 |
+ |
222 |
+Avoiding unnecessary user/group creation at build time is implemented |
223 |
+via correct dependency types. While this was possible with the status |
224 |
+quo, the dependency model should be more natural to developers and cause |
225 |
+less mistakes. |
226 |
+ |
227 |
+ |
228 |
+User/group removal |
229 |
+------------------ |
230 |
+ |
231 |
+The original proposal attempted to remove user/groups automatically |
232 |
+when the respective package was unmerged. This required verifying that |
233 |
+no files are owned by the user/group in question which was both |
234 |
+expensive in terms of I/O, and fragile. |
235 |
+ |
236 |
+This GLEP follows the best practice of leaving obsolete user/groups |
237 |
+accounts while ensuring that they are locked out properly. This |
238 |
+guarantees that no files with stale ownership are left |
239 |
+e.g. on unmounted filesystems) and that the same UID/GID is not reused |
240 |
+for another user/group. |
241 |
+ |
242 |
+ |
243 |
+Backwards Compatibility |
244 |
+======================= |
245 |
+ |
246 |
+This GLEP preserves backwards compatibility with the existing method |
247 |
+of user/group management. Both methods can coexist as long as necessary |
248 |
+for the transition period, and the same user/group can be governed |
249 |
+by both in parallel. |
250 |
+ |
251 |
+However, some of the advantages will only be reliable once the old |
252 |
+method is phased out, and only on new installations. This particularly |
253 |
+applies to fixed UIDs/GIDs. |
254 |
+ |
255 |
+ |
256 |
+Reference Implementation |
257 |
+======================== |
258 |
+ |
259 |
+The reference implementation has been submitted to review on gentoo-dev |
260 |
+mailing list. The version at the time of writing is v2. [#REFIMPL]_ |
261 |
+ |
262 |
+ |
263 |
+References |
264 |
+========== |
265 |
+ |
266 |
+.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs |
267 |
+ (https://www.gentoo.org/glep/glep-0027.html) |
268 |
+ |
269 |
+.. [#REFIMPL] [gentoo-dev] [PATCH v2 0/9] User/group packages |
270 |
+ (https://archives.gentoo.org/gentoo-dev/message/ccc85af0511f70ee9d3549b89bd8a40b) |
271 |
+ |
272 |
+ |
273 |
+Copyright |
274 |
+========= |
275 |
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
276 |
+Unported License. To view a copy of this license, visit |
277 |
+http://creativecommons.org/licenses/by-sa/3.0/. |
278 |
-- |
279 |
2.22.0.rc3 |