UID_MIN & GID_MIN changed

[Peter Vrabec]

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. :)

> >> * 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

> > 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. :)


> I notice that your patch on Monday to shadow-utils also canonicalized
> this in the login.defs for the first time.  Please revert that.
> 
> -Toshio