[853] in athena10
Re: The low UID/GID problem
daemon@ATHENA.MIT.EDU (Tim Abbott)
Thu Jan 15 17:58:34 2009
Date: Thu, 15 Jan 2009 17:57:43 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Mitchell E Berger <mitchb@mit.edu>
cc: debathena@mit.edu, athena10@mit.edu, ops@mit.edu
In-Reply-To: <200901110004.n0B04UXZ017676@byte-me.mit.edu>
Message-ID: <alpine.DEB.2.00.0901131446060.10258@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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.)
