1 |
On 6/9/2019 7:39 AM, Michał Górny wrote: |
2 |
> +Specification |
3 |
> +============= |
4 |
> + |
5 |
> +Policy |
6 |
> +------ |
7 |
> + |
8 |
> +Following the acceptance of this GLEP, all new users and groups must |
9 |
> +be created via user/group packages as defined in this GLEP. The old |
10 |
> +method may still be used for existing users/groups, in existing |
11 |
> +packages. |
12 |
> + |
13 |
> +All new users and groups must have unique UIDs/GIDs assigned |
14 |
> +by developers. The developer adding them is responsible for checking |
15 |
> +for collisions. |
16 |
|
17 |
What significance will such numbers have when a daemon uses a new |
18 |
UID/GID and really doesn't care what it is? Why do we have to go |
19 |
through the effort of assigning fixed IDs at random? |
20 |
|
21 |
> + |
22 |
> +Before adding a new user and/or group, the developer must send a RFC |
23 |
> +to the ``gentoo-dev`` mailing list. |
24 |
|
25 |
This paragraph should go away. It is a complete waste of time. |
26 |
|
27 |
|
28 |
> + |
29 |
> + |
30 |
> +Logical structure |
31 |
> +----------------- |
32 |
> + |
33 |
> +In this proposal, system users and groups are represented by regular |
34 |
> +packages. Those packages logically represent the ownership of |
35 |
> +the respective users and group, and technically implement their |
36 |
> +creation. |
37 |
> + |
38 |
> +User packages are placed in ``acct-user`` category. Each user package |
39 |
> +defines the properties of the particular user, and must be named after |
40 |
> +the user it creates. It must depend at build and run time on the groups |
41 |
> +the user belongs to. |
42 |
> + |
43 |
> +Group packages are placed in ``acct-group`` category. Each group |
44 |
> +package defines the properties of the particular group, and must be |
45 |
> +named after the group it creates. |
46 |
> + |
47 |
> +All user and group packages must define preferred fixed UIDs/GIDs, |
48 |
> +and they must be unique within the repository. The packages should |
49 |
> +indicate whether the value needs to be strictly enforced, or whether |
50 |
> +another UID/GID is acceptable when the user exists already or requested |
51 |
> +UID/GID is taken. |
52 |
> + |
53 |
> +Packages needing a specific user or group use dependencies to pull |
54 |
> +the required user/group packages. If the user is needed at build time, |
55 |
> +a build time dependency (``DEPEND``) must be used. If the user is |
56 |
> +needed at install and/or run time, a run time dependency (``RDEPEND``) |
57 |
> +must be used. |
58 |
|
59 |
Sounds like extra upgrade dependency time in an already crowded |
60 |
resolution tree. |
61 |
|
62 |
> + |
63 |
> +Rationale |
64 |
> +========= |
65 |
> + |
66 |
> +Requiring mailing list RFC |
67 |
> +-------------------------- |
68 |
> + |
69 |
> +The policy explicitly requires RFC-es for new users and groups, as they |
70 |
> +have global scopes and effects of mistakes while adding them are hard |
71 |
> +to fix. Wider review should decrease the risk of major design mistakes. |
72 |
> + |
73 |
> +To provide one example, right now we have two different packages |
74 |
> +creating ``git`` user and requiring a different home directory for |
75 |
> +the user. As a result, the first package being installed defines |
76 |
> +the actual home directory, and both technically can not be installed |
77 |
> +at the same time. |
78 |
|
79 |
This section should go away. It is a complete waste of time. |
80 |
|
81 |
> + |
82 |
> + |
83 |
> +Satisfied goals |
84 |
> +--------------- |
85 |
> + |
86 |
> +Tracking of user/group usage is done through dependencies. As long |
87 |
> +as any installed package depends on a specific user/group package, |
88 |
> +the respective user/group is assumed to be used. If no package |
89 |
> +requiring the specific user/group is left, the package manager |
90 |
> +automatically prunes the package clearly indicating it is no longer |
91 |
> +used. |
92 |
|
93 |
You cannot know when a name is "no longer used". An administrator could |
94 |
have adopted a username for other purposes. |
95 |
|
96 |
> + |
97 |
> +Each user and group has a single respective package creating it. |
98 |
> +If multiple packages need it, they depend on the same package. This |
99 |
> +ensures that all properties are kept in a single location, and do not |
100 |
> +need to be synced. |
101 |
> + |
102 |
> +Having a single location with all predefined user/group ranges makes it |
103 |
> +possible to maintain fixed UID/GID definitions. This GLEP makes |
104 |
> +allocating them obligatory. While this isn't enforced for existing |
105 |
> +users, it provides a way forward for new installations. |
106 |
> + |
107 |
> +Local overrides can be trivially implemented via local repository, |
108 |
> +through overriding the respective user/group ebuilds. The proposal also |
109 |
> +respects direct sysadmin modifications. |
110 |
> + |
111 |
> +Avoiding unnecessary user/group creation at build time is implemented |
112 |
> +via correct dependency types. While this was possible with the status |
113 |
> +quo, the dependency model should be more natural to developers and cause |
114 |
> +less mistakes. |
115 |
> + |
116 |
> + |