The FPC has recently been looking at a draft revision of the UID and Group handling: https://fedorahosted.org/fpc/ticket/269 https://fedoraproject.org/wiki/User:Mitr/UsersAndGroups This is an "interesting" draft on several fronts. Historically: * UID/GID allocation was one of the first major controversial guideline that the FPC decided upon. * The Guidelines specify that only dynamic UID and GID allocation is supposed to be used and the Guidelines give instructions for how sysadmins can adapt that to being static on a site-by-site basis by pre-allocating the uids. Despite this, some packages have added their own static uids and gids. This has lead to bugs. What things have changed since then? * New FPC members who might be able to either come up with something different or would vote differently on this * The 1000SystemAccounts[1]_ Feature of F16 has expanded the range of static system accounts. However, the range is still miniscule -- we only have from 0 to 200 and according to /usr/share/doc/setup-2.8.67/uidgid approximately 160 of those have already been allocated * As part of the 1000SystemAccount feature (IIRC), the allocation of system dynamic accounts was changed so that system dynamic accounts were allocated from the top of their range going down rather than from the bottom. This means that on boxes freshly installed after F16 the static range * fedora-usermgmt was what prompted the original uid/gid guidelines. The upstream author of that package has left fedora and there seems to be activity to remove the need for it from all remaining packages in the distro. This removes one of the sources of controversy that affected the original guidelines. .. [1]: http://fedoraproject.org/wiki/Features/1000SystemAccounts What does the current draft propose? * The draft needs some restructuring but the basic idea is that it would add a way for packages to request a static uid/gid when they are created but for that uid/gid to be overridden by the local sysadmin. What will that gain us? * If a sysadmin wants to modify the system id ranges for their site or pre-allocates ids (for instance, to match what another distribution does), they can do that with the soft-static allocation in the proposal. Sysadmins cannot do that currently with packages which do not conform to the Guidelines and allocate purely static uids and gids. Their systems are highly likely to simply end up broken (Unable to install the packages) * Out-of-the box sharing of files via a networked filesystem in a homogeneous Fedora (and possibly RHEL) environment. Sysadmins will have to modify the uids in heterogeneous networks because other distros have different ranges for their system uids. Things that we're considering adding to the draft: * Having a group be the gatekeeper for allocating the static uid and gids instead of that being solely the setup maintainer's responsibility. In the past the setup maintainers have often added static uids and gids without regard for whether they were needed or not. This leads to a scarcity of uids and gids. Both FPC and FESCo have been proposed as this group. I lean towards FPC since it is something where a lot of time has to be spent figuring out whether there really is a need for a static uid and then potentially instructing the packager as to why a dynamic uid is just as fitting for their use case as a static one. Some others propose FESCo as this is in the borderline between Guidelines and enforcement of Guidelines (enforcement being FESCo's jurisdiction). * Presently discussing whether static allocations should be done via scriptlets in the setup package and the scriptlets for adding uids and gids in the packages themselves will all be dynamic. Since the decision of what uid and gid is allocated is centralized, making the implementation actually be centralized has merit. It would also keep packagers from cargo culting a static allocation from a different package by mistake. However, it feels a little bit wrong. If someone can come up with a technical reason not to do this, please speak up. Some things I see us doing if we approve this revision: * All packages using hard static uid allocation will be converted to soft static allocation. - Usually, when guidelines are updated there is no requirement that the packages in the distro immediately adapt to the new guidelines. For this guideline, hard static allocations are actually a latent bug that sysadmins may not have reported but definitely could have run into. * Packages doing hard static allocation that aren't listed in the setup uidgid file should have their static allocation evaluated and be converted to dynamic if appropriate. * Some ways in which the useradd and groupadd scripts add dynamic system uids and gids should be treated as bugs and fixed. (In particular that they don't always allocate the highest available uid/gid in the SYS_UID range) https://bugzilla.redhat.com/show_bug.cgi?id=924501#c9 We (the FPC) would love to have feedback on the draft and comments to help iron out issues that it may cause. Ville: I am especially interested in what you have to say as the author of our current uid/gid guidelines. Thanks, -Toshio
Attachment:
pgpi_gNYR2eDu.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
