[819] in athena10
Re: sudo and group 101
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Sat Jan 10 17:11:12 2009
Date: Sat, 10 Jan 2009 17:10:25 -0500 (EST)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <49691C35.2060002@mit.edu>
Message-ID: <alpine.DEB.2.00.0901101709400.12262@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
I always assumed that sudo for cluster machines would be implemented by
using pam_group to add them at GDM login to the admin group. I don't
remember if I actually tried this.
--
Geoffrey Thomas
geofft@mit.edu
On Sat, 10 Jan 2009, Evan Broder wrote:
> 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
>
