On Thu, May 26, 2011 at 09:27:21AM +0200, Peter Vrabec wrote:
On Wednesday, May 25, 2011 08:07:32 PM Toshio Kuratomi wrote:
> On Wed, May 25, 2011 at 1:55 AM, Peter Vrabec <pvrabec(a)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(a)redhat.com>
> >> > Hi all,
> >> >
> >> > I'd like to inform you that I have changed UID_MIN & GID_MIN
> >> > to 1000 in upgraded shadow-utils.
> >> >
> >> > Where?
> >> > /etc/login.defs.
> >> > shadow-utils-184.108.40.206-1.fc16
> >> >
> >> > I suppose UID/GID_MIN=1000 is more common(other distros, upstream).
> >> > 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.
* Fri Mar 16 2007 Peter Vrabec <pvrabec(a)redhat.com> 2:220.127.116.11-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
> > 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.
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