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