[818] in athena10
sudo and group 101
daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Jan 10 17:08:47 2009
Message-ID: <49691C35.2060002@mit.edu>
Date: Sat, 10 Jan 2009 17:07:49 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: debathena@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Implementing sudo for cluster machines turns out to be harder than I
realized.
The group mit, which has GID 101, conflicts with...well, whatever the
first system group created on a Debathena system is. Typically this is
dhcp, but it does vary. Because group 101 exists on the local system, it
supersedes group mit, and nss_nonlocal removes users in group mit from
group 101.
It's conceivable that we could somehow renumber group 101 on the local
system at install time, but this is a fairly involved process. To do it
right, we'd want some kind of assurance that there aren't any files
chgrp'd to the old GID, or any daemons running as the old
GID...complicated, and probably hard to do reliably. Plus, we'd have to
maintain this hackage long into the future.
It seems like a far more future-proof solution would be to renumber
group mit to some number other than 101 - possibly something like 999.
This would certainly be hard now, but I'm wondering if it's actually
possible. The AFS GID field could be fixed with an AFS walk by something
like the janitor. What I don't know is if old Athena 9 machines would
adapt sanely to the GID changing.
If it was actually possibly to renumber group mit, it seems like that
would be a much better long-term solution. Would it actually be feasible
to do this?
- Evan
