UID_MIN & GID_MIN changed

[Toshio Kuratomi]

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.


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

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

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