[Fedora-packaging] Static UIDs and GIDs
a.badger at gmail.com
Thu Apr 11 18:57:02 UTC 2013
The FPC has recently been looking at a draft revision of the UID and Group
This is an "interesting" draft on several fronts.
* 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_ 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
* 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
.. : 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
- 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the packaging