[853] in athena10

home help back first fref pref prev next nref lref last post

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


home help back first fref pref prev next nref lref last post