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