On 6/9/2019 7:39 AM, Michał Górny wrote: > +Specification > +============= > + > +Policy > +------ > + > +Following the acceptance of this GLEP, all new users and groups must > +be created via user/group packages as defined in this GLEP. The old > +method may still be used for existing users/groups, in existing > +packages. > + > +All new users and groups must have unique UIDs/GIDs assigned > +by developers. The developer adding them is responsible for checking > +for collisions.
What significance will such numbers have when a daemon uses a new UID/GID and really doesn't care what it is? Why do we have to go through the effort of assigning fixed IDs at random? > + > +Before adding a new user and/or group, the developer must send a RFC > +to the ``gentoo-dev`` mailing list. This paragraph should go away. It is a complete waste of time. > + > + > +Logical structure > +----------------- > + > +In this proposal, system users and groups are represented by regular > +packages. Those packages logically represent the ownership of > +the respective users and group, and technically implement their > +creation. > + > +User packages are placed in ``acct-user`` category. Each user package > +defines the properties of the particular user, and must be named after > +the user it creates. It must depend at build and run time on the groups > +the user belongs to. > + > +Group packages are placed in ``acct-group`` category. Each group > +package defines the properties of the particular group, and must be > +named after the group it creates. > + > +All user and group packages must define preferred fixed UIDs/GIDs, > +and they must be unique within the repository. The packages should > +indicate whether the value needs to be strictly enforced, or whether > +another UID/GID is acceptable when the user exists already or requested > +UID/GID is taken. > + > +Packages needing a specific user or group use dependencies to pull > +the required user/group packages. If the user is needed at build time, > +a build time dependency (``DEPEND``) must be used. If the user is > +needed at install and/or run time, a run time dependency (``RDEPEND``) > +must be used. Sounds like extra upgrade dependency time in an already crowded resolution tree. > + > +Rationale > +========= > + > +Requiring mailing list RFC > +-------------------------- > + > +The policy explicitly requires RFC-es for new users and groups, as they > +have global scopes and effects of mistakes while adding them are hard > +to fix. Wider review should decrease the risk of major design mistakes. > + > +To provide one example, right now we have two different packages > +creating ``git`` user and requiring a different home directory for > +the user. As a result, the first package being installed defines > +the actual home directory, and both technically can not be installed > +at the same time. This section should go away. It is a complete waste of time. > + > + > +Satisfied goals > +--------------- > + > +Tracking of user/group usage is done through dependencies. As long > +as any installed package depends on a specific user/group package, > +the respective user/group is assumed to be used. If no package > +requiring the specific user/group is left, the package manager > +automatically prunes the package clearly indicating it is no longer > +used. You cannot know when a name is "no longer used". An administrator could have adopted a username for other purposes. > + > +Each user and group has a single respective package creating it. > +If multiple packages need it, they depend on the same package. This > +ensures that all properties are kept in a single location, and do not > +need to be synced. > + > +Having a single location with all predefined user/group ranges makes it > +possible to maintain fixed UID/GID definitions. This GLEP makes > +allocating them obligatory. While this isn't enforced for existing > +users, it provides a way forward for new installations. > + > +Local overrides can be trivially implemented via local repository, > +through overriding the respective user/group ebuilds. The proposal also > +respects direct sysadmin modifications. > + > +Avoiding unnecessary user/group creation at build time is implemented > +via correct dependency types. While this was possible with the status > +quo, the dependency model should be more natural to developers and cause > +less mistakes. > + > +
signature.asc
Description: OpenPGP digital signature
