[Fedora-packaging] Static UIDs and GIDs

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130411/dae17d46/attachment.sig>