UID_MIN & GID_MIN changed

[Dennis Gilmore]

On Tuesday, May 24, 2011 10:25:44 AM 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 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

Im with Toshio here  there is potential pitfalls with many legacy systems. 
there is also great potential that system ids from newer systems will clash 
with legacy ids in ldap and nis setups,  we really should make it a feature as 
it really deserves to be widely anounced.  not quietly on the list here where 
it will likely get forgoten until users are bitten when they start deploying 
f16 boxes.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110524/4a24e0ca/attachment.bin