[Fedora-packaging] Static UIDs and GIDs

[Toshio Kuratomi]

On Fri, Apr 12, 2013 at 09:24:09AM +0200, Ondrej Vasik wrote:
> On Thu, 2013-04-11 at 11:57 -0700, Toshio Kuratomi wrote:
> > 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
> 
> Just small corrections here - only 118 uids and 144 gids are reserved so
> far. You probably did just `cat uidgid | wc -l` - which is not telling
> you the real numbers.
> 
Actually, your numbers don't tell the whole story either.  I looked at the
uidgid file and saw that current practice (apparently, even when we had hit
the 100 limit and theoretically our only option would have been to fill
these gaps in the sub-100 range unless the static uids that were allocated
pre-1000SystemAccounts were then changed afterwards... which I assume didn't
happen since it would make them non-static) and saw that when a service
received only a uid it blocked the gid that it was paired with and the same
for gid.  For instance: quaggavt uses only gid 85 but not thee uid.  sabayon
uses uid 86 and gid 86 instead of uid 85 gid 86.

So as current policy it looks like (wc -l uidgid) - 3 (for the headers and
footers) is a better estimate than looking at the actual number of allocated
uids and gids.

Now when pressure again mounts and we have no more free to allocate uids and
gids we could decide to allocate non-matching uids and gids.  However, that
still leaves us with the intertwined nature of uids and gids.  Running out
of either uids or gids will block packages that have need of that resource
or both resources.  So in this scenario it might be most accurate to think
of our current usage as max(uid, gid).

> Anyway - you are right, we have more than 40% of new space already used
> in less than 4 years (actually this increase was not part of the
> 1000SystemAccounts feature, but came earlier, as 100 static id's stopped
> to be enough in summer 2009). The trend of static ids request is
> increasing, especially because of openstack (cloud), so current
> allocation space is enough for 2-3 years. We may go cheap way and
> increase the static threshold to 300 if necessary - if done properly, it
> should not harm anyone, as the dynamically allocated systemid's are
> going downwards from the upper limit ( some warning for 1-2 releases, if
> someone uses the id's in the 200-300 area and than doing the change).
> 
Except where that's not the case (See mitr's bug report linked from the
original email or the ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=924501#c9 ).  I'm hoping that
this can be considered a bug though.

if we do allocate more static ids, we should definitely go beyond 300 (I
made a similar argument when 1000SystemAccounts was proposed but it seems to
have been ignored.)  100 more ids is simply not enough.  Also, static ids
are much less forgiving of site customization and sharing than dynamic ids.
So making the static id range much smaller than the dynamic id range doesn't
make a lot of sense.

> Still - even the increase of the static ids range and the increase of
> system account rang is not in line with LSB specification, which is
> pretty strict there (0-100 and 0-500). 
> 
Although I may agree with this sentiment I think that we had this discussion
when 1000SystemAccounts was approved.  So we've already crossed the point
where we have the possibility of complying with that portion of the LSB
specification.

-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/20130412/25f9b7a3/attachment.sig>