[6114] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Dec 4 19:45:01 2008
From: Ken Raeburn <raeburn@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
In-Reply-To: <1228427212.32231.41.camel@cheshire-cat.mit.edu>
Message-Id: <9F61FD34-DDBF-4E0A-B0BA-78EAFC7635FA@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 4 Dec 2008 19:44:15 -0500
Cc: release-team@mit.edu, morzinski@mit.edu, ghudson@mit.edu, athena10@mit.edu
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Dec 4, 2008, at 16:46, Bill Cattey wrote:
> I am concerned that if we change attach to infer a mount point from a
> location that we're throwing away an important part of the Hesiod
> abstraction that enables us to separate filesystem location from mount
> point.
Actually, the file system's source location (nfs host:path, afs path)
is still separate -- as I understand the proposal, the mount point and
Hesiod name become tied together, but for example /mit/x11r12 --
Hesiod name "x11r12" -- could map to NFS volume gobbledygook.mit.edu:/
u1/moviefone if that's what the creator of the hesiod data wanted to
set up.
And we've thrown away "important" things before as the technology
changed; when AFS showed up, "-w" and "-r" stopped being reliable,
"detach" didn't really make things go away, remote login sessions
couldn't necessarily access things you'd attached from the console, etc.
> In hallway chat, broder made the point that /mit as implemented in
> debathena is really an abstract filesystem used as an access point for
> filesystems accessed by attach. If I understand the fuse
> implementation
> correctly, we're leveraging simple stock issue code to get 80% of the
> user-visible functionality of attach.
Cool! Are we going to get sshfs and encfs as standard parts of Athena
10? I've been using them for a while now on my Mac, and they're
*very* nice.
> Hesiod/attach was originally a particular triple:
Well, a mapping from a name to a tuple...
> Type Location Mount Point
... which mount point can be overridden by the user of attach; and a
read/write/no-auth flag that can also be overridden, and which is of
limited use with AFS.
> Type enabled rich parsing of location and mount point names.
Did the file system type actually have anything to do with handling of
the mount point name? (How the mount is done -- create a directory
and call mount() vs create a symlink -- sure, but processing the name?)
> Presumably FUSE and other auto-mounter technology is rich enough
> that we
> can support more than just AFS mounts if there is compelling reason to
> in future. (In my ignorance, maybe it already does.)
Pretty easily, from what I've read, but I haven't tried using the
automounting tools.
> In the early days when attach was used to mount system packs served up
> in byte-order dependent remote virtual disk packs, with server-imposed
> limitations on names, there was compelling need to de-couple name from
> mount point. Jacob's analysis of present usage shows that there is
> only
> a minority of lockers using this de-coupling, and this thread has
> worked
> around to asking the question, "Is there compelling need to continue
> offering this de-coupling?"
It sounds like the most common use recently has been for providing
different versions of OS software based on the requested name, always
mounted at the same point. And that's not going to be relevant to
Athena 10.
> For now, I'd feel more comfortable keeping the attach -m option, and
> in
> having the Athena 10 implementation pull the mount point from the
> filsys
> tuple if it can be done without a lot of code, and if it isn't a
> serious
> security compromise.
The way it's done now is already a security issue. After all, if I
can spoof your workstation's DNS query with a fake record that maps
wdc.filsys.ns.athena.mit.edu to AFS path /afs/raeburn.org/h4x0r/wdc,
you may notice something's gone wrong, but probably not before your
login session has begun, under my control....
Our standard attach.conf restricts where the local mount points can be
set, and I'm not sure but I think that includes mount points derived
from Hesiod data (it certainly should!), so the damage to local host
security can be reduced, but the user is at the mercy of network
spoofing tools.
Ken
