1 |
Hi Michal, |
2 |
|
3 |
This sounds sensible and is an interesting approach. I kinda like it. |
4 |
|
5 |
There is only one technical comment I have based on the earlier |
6 |
discussion, not addressed. |
7 |
|
8 |
What if users needs to be created into a centralized UID/GID system to |
9 |
be pulled in via nss? |
10 |
|
11 |
So calling system tools by default is fine, but what if the sysadmin |
12 |
would prefer to have users and groups pushed into ldap? Can we at least |
13 |
accomodate a hook mechanism to allow system administrators not relying |
14 |
on local users to deal with this? |
15 |
|
16 |
My personal rule of thumb is that system users are (and should be) |
17 |
local. But there are definite use cases where shared "system uids" are |
18 |
a definite legitimate requirement. |
19 |
|
20 |
The one complaint I do have is repo bloat. |
21 |
|
22 |
Further comments below. |
23 |
|
24 |
Kind Regards, |
25 |
Jaco |
26 |
|
27 |
On 2019/05/29 09:28, Michał Górny wrote: |
28 |
> Motivation |
29 |
> ========== |
30 |
> |
31 |
> User management in Gentoo is currently ad-hoc. Users and groups are |
32 |
> created through calling system tools directly in packages needing them. |
33 |
> There is no systematic way of tracking which packages need specific |
34 |
> users or groups, and determining which ones are obsolete. Coordinating |
35 |
> properties of users and groups used by multiple packages must be done |
36 |
> manually by developers. |
37 |
> |
38 |
> GLEP 27 originally attempted to address the problem. Posted in 2004, |
39 |
> it never had reached the reference implementation state, and became |
40 |
> obsolete. [#GLEP27]_ |
41 |
> |
42 |
> A good system user and group management proposal should address: |
43 |
> |
44 |
> 1. Tracking usage of users and groups, and determining which ones |
45 |
> are obsolete. |
46 |
> |
47 |
> 2. Sharing users and groups reliably between different packages. |
48 |
> |
49 |
> 3. Maintaining fixed UIDs/GIDs that are consistent between different |
50 |
> systems. |
51 |
> |
52 |
> 4. Providing local overrides for user/group properties. |
53 |
> |
54 |
> 5. Ensuring that users and groups are not created unnecessarily |
55 |
> at build time. |
56 |
> |
57 |
> At the same time, the proposal should avoid unnecessary complexity |
58 |
> to avoid sharing the fate of GLEP 27. This proposal aims to address |
59 |
> those points without requiring a new EAPI or any changes in the package |
60 |
> manager. |
61 |
|
62 |
This looks good. I'd add "6. Allow for centralized management of users |
63 |
and/or groups" (in order to cover management via for example ldap). |
64 |
|
65 |
> Maintaining users/groups |
66 |
> ------------------------ |
67 |
> |
68 |
> The primary technical function of user and group packages is to create |
69 |
> the users and groups. This is done via invoking the respective system |
70 |
> tools at ``pkg_preinst`` phase. This is done only if the user/group |
71 |
> does not exist on the system already. |
72 |
|
73 |
I would recommend that this be handled via an eclass that deals with the |
74 |
technicalities. The package then does something like: |
75 |
|
76 |
inherit userpackage |
77 |
|
78 |
USER_NAME=mail |
79 |
USER_UID=8 |
80 |
USER_PRIMARY_GROUP=mail |
81 |
USER_FORCE_UID=yes |
82 |
|
83 |
DEPEND=group/mail |
84 |
RDEPEND=group/mail |
85 |
|
86 |
And that ends up being the whole package. Similar for groups. Even the |
87 |
R?DEPEND can probably go into the eclass. |
88 |
|
89 |
The eclass can then potentially support external hooks or something to |
90 |
accomodate 6. above. |
91 |
|
92 |
> |
93 |
> User/group name/identifier collision detection |
94 |
> ---------------------------------------------- |
95 |
> |
96 |
> The user/group packages can install additional files in subdirectories |
97 |
> of ``/var/lib`` indicating their respective names and identifiers. |
98 |
> This ensures that if two packages ever happen to collide, the package |
99 |
> manager's collision detection mechanism will trigger. |
100 |
|
101 |
Ulrich also commented on this. How about enforcing a mapping from |
102 |
$USER_NAME to package name? (ie, just replace all characters not |
103 |
allowed in package naming with _ or -. |
104 |
|
105 |
Same as Ulrich I struggle to see any use-case where this would be an |
106 |
issue, but artificial or not it's probably a good idea to deal with it |
107 |
somehow. |
108 |
|
109 |
> Naming rules |
110 |
> ------------ |
111 |
> |
112 |
> It has been pointed out that the package naming rules are more |
113 |
> restrictive than user/group naming rules. This is why the proposal |
114 |
> allows for package names to be different from user/group names. |
115 |
> However, this is strongly discouraged and should only be used when |
116 |
> really necessary. |
117 |
|
118 |
I would personally disallow it and enforce a mapping from username to |
119 |
package name. The question then however is if two names map to the same |
120 |
package (which would be confusing to begin with) how to deal with that. |
121 |
|
122 |
> User/group updates |
123 |
> ------------------ |
124 |
> |
125 |
> If sysadmin needs to change the properties (e.g. home directory) of some |
126 |
> user/group, the obvious course of action is to modify the system |
127 |
> databases directly. The GLEP aims to respect that and disallow altering |
128 |
> existing user/groups unconditionally. If any updates need to be done, |
129 |
> the packages need to verify previous values first. |
130 |
|
131 |
"If any updates need to be done, the package need to verify previous |
132 |
values first." conflicts with "disallow altering existing user/groups |
133 |
unconditionally". I'd rephrase as "If any updates need to be done, |
134 |
refer those to the system administrator." |
135 |
|
136 |
> User/group removal |
137 |
> ------------------ |
138 |
> |
139 |
> The original proposal attempted to remove user/groups automatically |
140 |
> when the respective package was unmerged. This required verifying that |
141 |
> no files are owned by the user/group in question which was both |
142 |
> expensive in terms of I/O, and fragile. |
143 |
> |
144 |
> This GLEP follows the best practice of leaving obsolete user/groups |
145 |
> accounts intact. This guarantees that no files with stale ownership are |
146 |
> left (e.g. on unmounted filesystems) and that the same UID/GID is not |
147 |
> reused for another user/group. |
148 |
|
149 |
The type of checks for both this and certain updates contemplated above |
150 |
are similar. And expensive (resources) as you rightly say. I would |
151 |
provide the tools to perform these checks but in the ebuild I'd rather |
152 |
the checks be done asap (pkg_pretend?). If we can fail there and |
153 |
stating what the admin should do to rectify the issue that would be the |
154 |
best solution in my personal opinion. Ie, from the package manager I'd |
155 |
state how, but not actually action these changes. |
156 |
|
157 |
I would suggest the GLEP restrict the scope of responsibility in this |
158 |
respect. I would recommend ensuring that the account is locked at last. |
159 |
|
160 |
Would repoman be able to validate unique UID and GID assignments for |
161 |
these user/ and group/ packages and enforce use of an eclass for these |
162 |
packages? |
163 |
|
164 |
Kind Regards, |
165 |
Jaco |