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
Attachment:
pgpUvsTZ2h1EL.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
