On Wed, 2019-05-29 at 11:50 +0200, Jaco Kroon wrote: > Hi Michal, > > This sounds sensible and is an interesting approach. I kinda like it. > > There is only one technical comment I have based on the earlier > discussion, not addressed. > > What if users needs to be created into a centralized UID/GID system to > be pulled in via nss? > > So calling system tools by default is fine, but what if the sysadmin > would prefer to have users and groups pushed into ldap? Can we at least > accomodate a hook mechanism to allow system administrators not relying > on local users to deal with this?
We kinda have hooks already. Just drop your 'useradd' etc. replacements into /usr/local/bin, and tadaam! KISS all the way. > My personal rule of thumb is that system users are (and should be) > local. But there are definite use cases where shared "system uids" are > a definite legitimate requirement. > > The one complaint I do have is repo bloat. > > Further comments below. > > Kind Regards, > Jaco > > On 2019/05/29 09:28, Michał Górny wrote: > > Motivation > > ========== > > > > User management in Gentoo is currently ad-hoc. Users and groups are > > created through calling system tools directly in packages needing them. > > There is no systematic way of tracking which packages need specific > > users or groups, and determining which ones are obsolete. Coordinating > > properties of users and groups used by multiple packages must be done > > manually by developers. > > > > GLEP 27 originally attempted to address the problem. Posted in 2004, > > it never had reached the reference implementation state, and became > > obsolete. [#GLEP27]_ > > > > A good system user and group management proposal should address: > > > > 1. Tracking usage of users and groups, and determining which ones > > are obsolete. > > > > 2. Sharing users and groups reliably between different packages. > > > > 3. Maintaining fixed UIDs/GIDs that are consistent between different > > systems. > > > > 4. Providing local overrides for user/group properties. > > > > 5. Ensuring that users and groups are not created unnecessarily > > at build time. > > > > At the same time, the proposal should avoid unnecessary complexity > > to avoid sharing the fate of GLEP 27. This proposal aims to address > > those points without requiring a new EAPI or any changes in the package > > manager. > > This looks good. I'd add "6. Allow for centralized management of users > and/or groups" (in order to cover management via for example ldap). I thought this is implied by other points but I guess saying it explicitly doesn't hurt. > > > Maintaining users/groups > > ------------------------ > > > > The primary technical function of user and group packages is to create > > the users and groups. This is done via invoking the respective system > > tools at ``pkg_preinst`` phase. This is done only if the user/group > > does not exist on the system already. > > I would recommend that this be handled via an eclass that deals with the > technicalities. The package then does something like: This is the plan. There is already an old version in mjo's overlay, and I'm planning to put a new one today for review. > > inherit userpackage > > USER_NAME=mail > USER_UID=8 > USER_PRIMARY_GROUP=mail > USER_FORCE_UID=yes > > DEPEND=group/mail > RDEPEND=group/mail > > And that ends up being the whole package. Similar for groups. Even the > R?DEPEND can probably go into the eclass. > > The eclass can then potentially support external hooks or something to > accomodate 6. above. > > > User/group name/identifier collision detection > > ---------------------------------------------- > > > > The user/group packages can install additional files in subdirectories > > of ``/var/lib`` indicating their respective names and identifiers. > > This ensures that if two packages ever happen to collide, the package > > manager's collision detection mechanism will trigger. > > Ulrich also commented on this. How about enforcing a mapping from > $USER_NAME to package name? (ie, just replace all characters not > allowed in package naming with _ or -. > > Same as Ulrich I struggle to see any use-case where this would be an > issue, but artificial or not it's probably a good idea to deal with it > somehow. This is not so simple. The main concern are names like 'foo-1'. But I guess we can leave it out for now, and address it when we actually have a need for such user/group. > > > Naming rules > > ------------ > > > > It has been pointed out that the package naming rules are more > > restrictive than user/group naming rules. This is why the proposal > > allows for package names to be different from user/group names. > > However, this is strongly discouraged and should only be used when > > really necessary. > > I would personally disallow it and enforce a mapping from username to > package name. The question then however is if two names map to the same > package (which would be confusing to begin with) how to deal with that. > > > User/group updates > > ------------------ > > > > If sysadmin needs to change the properties (e.g. home directory) of some > > user/group, the obvious course of action is to modify the system > > databases directly. The GLEP aims to respect that and disallow altering > > existing user/groups unconditionally. If any updates need to be done, > > the packages need to verify previous values first. > > "If any updates need to be done, the package need to verify previous > values first." conflicts with "disallow altering existing user/groups > unconditionally". I'd rephrase as "If any updates need to be done, > refer those to the system administrator." I suppose the meaning of 'unconditionally' is ambiguous here. > > > User/group removal > > ------------------ > > > > The original proposal attempted to remove user/groups automatically > > when the respective package was unmerged. This required verifying that > > no files are owned by the user/group in question which was both > > expensive in terms of I/O, and fragile. > > > > This GLEP follows the best practice of leaving obsolete user/groups > > accounts intact. This guarantees that no files with stale ownership are > > left (e.g. on unmounted filesystems) and that the same UID/GID is not > > reused for another user/group. > > The type of checks for both this and certain updates contemplated above > are similar. And expensive (resources) as you rightly say. I would > provide the tools to perform these checks but in the ebuild I'd rather > the checks be done asap (pkg_pretend?). If we can fail there and > stating what the admin should do to rectify the issue that would be the > best solution in my personal opinion. Ie, from the package manager I'd > state how, but not actually action these changes. > > I would suggest the GLEP restrict the scope of responsibility in this > respect. I would recommend ensuring that the account is locked at last. Yes, I've forgotten about this part. Locking it out is a good idea. > Would repoman be able to validate unique UID and GID assignments for > these user/ and group/ packages and enforce use of an eclass for these > packages? > Not in the current design. PkgCheck should be able to handle this though. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
