UID_MIN & GID_MIN changed

[Toshio Kuratomi]

On Thu, May 26, 2011 at 09:27:21AM +0200, Peter Vrabec wrote:
> Hi, 
> 
> On Wednesday, May 25, 2011 08:07:32 PM Toshio Kuratomi wrote:
> > On Wed, May 25, 2011 at 1:55 AM, Peter Vrabec <pvrabec at redhat.com> wrote:
> > > Hi,
> > > 
> > > On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
> > >> On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec <pvrabec at redhat.com> wrote:
> > >> > Hi all,
> > >> > 
> > >> > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500
> > >> > to 1000 in upgraded shadow-utils.
> > >> > 
> > >> > Where?
> > >> > /etc/login.defs.
> > >> > shadow-utils-4.1.4.3-1.fc16
> > >> > 
> > >> > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
> > >> > are not in situation that 500 IDs for system accounts ought to be
> > >> > enough for anybody. Actually, it was not 500.It was 299 because range
> > >> > 0-200 is for reserved IDs. There are 799 non reserved IDs for system
> > >> > accounts available after this change.
> > >> 
> > >> This change should be made as a Feature for F16 and needs some
> > >> thought/coordination put behind it.  There's several issues that I
> > >> see:
> > >> 
> > >> * AFAIK, we actually have not run into the 500 uid limit yet (although
> > >> it is a bit low to be comfortable)
> > >> *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
> > >> * The 0-100 reserved IDs are actually the pain point that we need to
> > >> deal with, not the dynamic system ids in the 101-499 range.
> > > 
> > > We use 0-200 for reserved IDs  since
> > > http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html
> > 
> > If people think that 0-200 was the conclusion to that thread, it would
> > explain why there's a few buggy accounts in
> > /usr/share/doc/setup*/uidgid :-(  But that was not the conclusion of
> > that thread.  Of the available range, using 100-200 is an especially
> > bad choice for expanding the range.  Dynamically allocated system
> > accounts fall into that space and since allocation goes from the
> > bottom up, there's likely to be collisions. If we decided that 399-499
> > was also a range for static uids, the changes of collisions would
> > still exist but be much lower.
> This is not true.
> 
> Changelog:
> * Fri Mar 16 2007 Peter Vrabec <pvrabec at redhat.com> 2:4.0.18.1-11
> - assign system dynamic UID/GID from the top of available UID/GID (#190523)
> 
> Some people were expecting this issue. :)
> 
Ah so it does.  I suppose that tells you how long ago its been since my
machine has had a fresh install :-)

> > >> * We don't know how many, if any IDs this actually gets us for the
> > >> dynamic range because any site that has already filled the 500-1000
> > >> UID range won't gain any extra dynamic system account through this
> > >> change.
> > >> * This could potentially break sites that are currently using the
> > >> 500-1000 UID range and rely on the order of allocation of UIDs for
> > >> their users on new machines matching with the UIDs on old machines.
> > >> (For instance, NFS UIDs on filesystems matching between a box
> > >> installed with RHEL5 and a box that gets newly installed with F16).
> > >> 
> > >> -Toshio
> > > 
> > > I'm not against wider announcement. I'm just not sure what is the right
> > > way - F16 Feature/Release Notes/ .... ?
> > 
> > Yes, we can release note it.  But you still haven't answered the
> > question of why this change is necessary.  Do you really have a system
> > where you have installed more than 400 packages that are allocating
> > dynamic system accounts?
> 1. I'd like to avoid it.
> 2. interoperability
> 
What us "it" that you'd like to avoid?


> > > We can also annouce the 200 limit for reserved IDs. ;)
> > 
> > We can't just make changes to this range.  Especially not in the lower
> > end of it.  (and if we change the dynamic system account range to
> > extend higher, we also can't use the 500-1000 range for that.
> This change has already happened. If it was done without any harm, I consider 
> that a good job. :)
> 
To be clear, this change has only happened in rawhide with your last commit
so it's a bit early to tell what harm there is.  With the clarification that
the dynamic UID range has started allocating at the top instead of the
bottom in 2007, it makes a lot more sense that we can make this change.  Are
you sure you only want to allocate 0-200, though?  Remember that the static
assignments are our limited resource, perhaps you want to go higher than
that?

-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/devel/attachments/20110531/d4369e82/attachment-0001.bin