[26186] in Athena Bugs
Re: attach -m
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Nov 17 10:01:02 2004
From: Greg Hudson <ghudson@mit.edu>
To: seph <seph@mit.edu>
In-Reply-To: <w52hdnpt5qv.fsf@lame.message.id>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100703611.29606.167.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Date: Wed, 17 Nov 2004 10:00:11 -0500
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
On Wed, 2004-11-17 at 00:16, seph wrote:
> playing around on brute-force, a Athena Server (sun4) Version 9.3.15
> I noticed that attach treats the -m option rather oddly. All this was
> done as a user, no root access.
There is also a set of trusted users defined in
/etc/athena/attach.conf. I'll assume for the moment
> 0:02 brute-force[2]:~% attach -n -h -t AFS -e /afs/athena/user/s/e/seph/mount-test/ -m /test
> /afs/athena/user/s/e/seph/mount-test/: You are not allowed to attach a locker on /mit
Perhaps the most confusing aspect of attach's option parsing is that the
-e option does not take an argument. Also, it uses the non-permuting
kind of option parsing, so you can't specify options after a
command-line argument. So this was interpreted as options {-n} {-h} {-t
AFS} {-e} followed by arguments {/afs/athena/user/s/e/seph/mount-test/}
{-m} {/test}.
So, attach tries to do an explicit mount of
/afs/athena/user/s/e/seph/mount-test/ with no specified mount point.
The default mount point is "/mit/blah", where "blah" is the last path
component of the explicit path. (The "/mit" part is configurable in
attach.conf as the afs-mount-dir option, though we don't set it in the
stock attach.conf.) Since the explicit path ended with a trailing
slash, blah was empty, and you tried to attach something onto /mit.
So, every component of the system is performing to specification, but
there is room for improvement. Arguably, attach should do permuting
option parsing. And the default mountpoint selection for explicit
mountpoints should notice and ignore a trailing slash on the mountpoint.
> 0:02 brute-force[2]:~% attach -n -h -t AFS -m /test -e /afs/athena/user/s/e/seph/mount-test/
> attach: /afs/athena/user/s/e/seph/mount-test/ attached to /test for filesystem /afs/athena/user/s/e/seph/mount-test/
Hm, my understanding was that users should only be allowed to mount
filesystems under /mit; otherwise, I'm not sure what the "mountpoint
/mit/[^/]*" line in attach.conf is supposed to do. But I can reproduce
this behavior. So this is probably a bug.
> 0:05 brute-force[2]:~% attach -n -h -t AFS -m /opt/test -e /afs/athena/user/s/e/seph/mount-test/
> /afs/athena/user/s/e/seph/mount-test/: You are not allowed to attach a locker on /opt/test
That's a result of the "nomountpoing ^/opt" directive functioning
correctly.
> I assume it's intentional that I can't specify /opt/test as a mount
> point, but it seems odd that I can specify /test. It seems equally odd
> that if I specify the -m option last, I get a very strange error. I'm
> not even sure I should be allowed to use -m as a normal user (though
> it's a feature I've appreciated)
It's not clear how you maintain a replicated locker without the ability
to do explicit mounts under /mit. But you're right that it has security
implications on a multi-user machine.
> Lastly, it's confusing having both a athena/bin/attach/attach.c and a
> athena/lib/locker/attach.c
I can see how it would be a mild inconvenience when using gdb, but I
don't see how it's confusing. And it's the natural name for a file
handling the "attach" command of the attach suite, as well as the
natural name for a file handling the locker-attaching functionality
within liblocker.
