[827] in athena10

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

Re: The low UID/GID problem

daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Sat Jan 10 19:05:29 2009

Message-Id: <200901110004.n0B04UXZ017676@byte-me.mit.edu>
To: Tim Abbott <tabbott@MIT.EDU>
cc: debathena@MIT.EDU, athena10@MIT.EDU, ops@MIT.EDU
In-Reply-To: Your message of "Sat, 10 Jan 2009 17:28:12 EST."
             <alpine.DEB.2.00.0901101653110.21723@opus.mit.edu> 
Date: Sat, 10 Jan 2009 19:04:29 -0500
From: Mitchell E Berger <mitchb@MIT.EDU>

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

Mitch

> Along with the "mit" group problem that broder just sent mail about, there 
> is a broader but much easier problem with Athena users with low UIDs that 
> might conflict with the UID of a system user on a Debathena machine at 
> some point in the future (which would prevent them from logging in).
> 
> I think that this is a problem that we'll want to solve soon, rather than 
> waiting for users to complain that they can't log in.
> 
> /mit/tabbott/Public/users-who-lose contains a list of the 52 Athena 
> accounts with a uid below 200 (I'm ignoring accounts such as "Mr Kernel" 
> that probably cannot log in).
> 
> I think the right solution to this is to renumber these 52 people's 
> accounts and change Moira to no longer assign UIDs to new accounts below 
> 200 (if it still does).  It's a small enough list that we could feasibly 
> renumber their accounts, and it should protect us from UID conflicts with 
> system groups for a long time.
> 
> 
> The other UID range that might have potential problems is 1000-1100, the 
> range where local UNIX users would be assigned.  It would be good to 
> reserve these in Moira as well, so that when accounts in that range expire 
> they do not get replaced.  But this range is less critical as it won't 
> affect cluster machines.
> 
> 
> There's also groups that might conflict with system groups (see 
> /mit/tabbott/Public/groups-who-lose for all 24 of them below 200).  These 
> groups simply will be useless on Debathena machines that have a system 
> group with the same number.  Renumbering those of these other than "mit" 
> is probably easier than renumbering users, because they should not appear 
> in AFS (as all Athena users have gid 101), but it is also less critical 
> than the UID problem.
> 
> 
> I've CCed ops on this thread, since they would likely be involved in any 
> renumberings.
> 
>  	-Tim Abbott

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