[854] in athena10
Re: The low UID/GID problem
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Jan 15 21:01:05 2009
Cc: Mitchell E Berger <mitchb@mit.edu>, debathena@mit.edu, athena10@mit.edu,
ops@mit.edu
Message-Id: <D31BB5EF-631A-49EB-8018-35ECE80AC4D0@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0901131446060.10258@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 15 Jan 2009 21:00:00 -0500
Renumbering is the right thing to do here. We've already seen UID
collisions on Athena 9, and it's just going to get worse.
Fixing /etc/passwd and /etc/group on Athena machines is easy enough.
I'm even willing to go on site visits for this, considering how small
the group is. Fixing local storage is also easily with chown -R.
I move to call the question.
-Jon
On Jan 15, 2009, at 5:57 PM, Tim Abbott wrote:
> The way I see it, we have basically 3 choices:
>
> (1) Do nothing. The result is that these users cannot log in to
> Athena 10, and anybody listing files they own in AFS discovers that
> those files are actually owned by the "pyhesiodfs" user or whatever.
>
> (2) Try to write a maintain a pile of hacks to renumber system users
> when one installs debathena-workstation, and prevent new system
> users from being created in the relevant ranges. As the person who
> renumbered system accounts during Linerva development, I can tell
> you this will be very unpleasant.
>
> (3) Renumber the users. We have to do some work contacting these
> people so that we can coordinate the renumbering with renumberings
> of any local disk or NFS data that they have tied to their Athena
> account. Probably most of them don't have any, given how recent
> these people's AFS home directories' "Last Update" dates are.
>
> I think that the short-term headache associated with option (3) is a
> much better plan than options (1) and (2). It sounds like you're
> saying that this process involves more than just doing some
> operations in AFS in the middle of the night, and that we'll need to
> make contact with users? That was certainly my expectation.
>
> If we come to the conclusion that renumbering is the path we're
> going to take, then we can move on to discussing how to handle the
> communication with users.
>
> -Tim Abbott
>
> On Sat, 10 Jan 2009, Mitchell E Berger wrote:
>
>> This seems an awfully AFS-centric proposal, no? A lot of the people
>> on that list (probably all of them) are fairly crufty, and likely
>> either have or had private workstations or have access to such boxes.
>> If you change their UID, this may well screw them over by revoking
>> access
>> to files they stored on local disk on private machines, no? I
>> suppose
>> that many of them are from the old days where we granted access to
>> Athena machines by putting the hesiod info into /etc/passwd.local
>> rather than putting the username in /etc/athena/access. On those
>> machines,
>> their UID wouldn't change automatically, of course, which would
>> save them from this screw case.
>>
>> (I bet you thought I was going to say it would break NFS... I don't
>> really know how knfs worked or whether this is a problem. But while
>> we don't really support NFS any more, we do support using local disk
>> on private machines.)
>
