[5765] in Release_7.7_team
Re: expanding Athena UNIX UID space
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Thu Apr 26 15:38:00 2007
Message-Id: <200704261937.l3QJbG9j027541@speaker-for-the-dead.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Garry Zacheiss <zacheiss@MIT.EDU>
cc: moira-admin@MIT.EDU, release-team@MIT.EDU, athena-rcc@MIT.EDU
In-reply-to: Your message of "Wed, 25 Apr 2007 15:33:59 EDT."
<200704251933.l3PJXxd3000887@brad-majors.mit.edu>
Date: Thu, 26 Apr 2007 15:37:16 -0400
X-Spam-Flag: NO
X-Spam-Score: 0.00
> I noticed the other day that we're almost out of free UIDs in moira, and
> will need to do another purge soon. (moira-admin, expect mail about that
> later today).
>
> However, that got me thinking that it would be good if we could expand
> our space of available UIDs, since as far as I know, neither recent
> Solaris or Linux limit the size of UIDs to an unsigned short anymore.
>
> To that end, I've resurrected the "hightest" test account and bumped its
> UID to 90000 for purposes of testing. I've done some testing with it,
> and I've asked Greg and Laura to do some as well. So far, we've tested
> logins via xlogin, SSH, telnet, ftp, rlogin, etc. without ill effects.
> "ls" and "id" output also appears sane.
>
> As such, my questions are:
>
> 1.) Do we wish to formally proceed with doing this? I really think we
> do.
>
> 2.) How formal a testing process do we want to use if we choose to
> proceed?
>
> and the related:
>
> 3.) Is anyone aware of any systems other than Athena logins (via hesiod
> passwd entries) and AFS that this information is exposed to that need
> to be tested?
>
> 4.) What additional ID space do we want to use? My initial thought was
> that we want to open up the space through 99999, and reserve those
> UIDs that conflict with existing AFS pts IDs for root instances. We
> would simultaneously change the algorithm we use for generating pts
> ids for root instances to prevent any further conflicts.
>
> Greg proposed the alternate idea of beginning to allocate IDs above
> 131072 to avoid any root instance conflicts, which also seems like a
> reasonable alternative.
>
> There's also one related (although less important) question:
>
> 5.) We currently avoid handing out UIDs between 32000 and 32768 because
> they interacted poorly with Ultrix. Is there any reason for us to
> keep doing this?
>
> I welcome any thoughts on how to proceed.
I discussed this with Garry the other day, but for the record:
Yes, I think this is a good idea
The testing Garry, Laura, etc. have already done covers all of the
things that I can think of that need testing, at a level of formality
that I consider sufficient.
I'm fine with either Garry's or Greg's suggestions for what UID space
to use next (or for that matter assigning from 65536-131071). No, I
don't think we need to preserve 'the Ultrix hole' in our UID space.
Jonathon
