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. :) > >> * 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
