[26187] in Athena Bugs
attach -m
daemon@ATHENA.MIT.EDU (seph)
Wed Nov 17 11:07:37 2004
To: bugs@mit.edu
From: seph <seph@mit.edu>
Date: Wed, 17 Nov 2004 11:07:00 -0500
Message-ID: <w524qjotq6z.fsf@lame.message.id>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Errors-To: bugs-bounces@mit.edu
> There is also a set of trusted users defined in
> /etc/athena/attach.conf. I'll assume for the moment
ah. glancing at brute-force's attach.conf, it looks pretty typical.
> Perhaps the most confusing aspect of attach's option parsing is that the
> -e option does not take an argument.
ah, that'd be user error then. not a bug.
>> 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.
looking at the attach.conf, it explicitly forbids mounting on a bunch
of important places. and then has:
nomountpoint ^/mit/[^/]*/. ^/\.
mountpoint /mit/[^/]*
I suspect the nomountpoint line should just get ^/, though that may
end up interfering with mountpoint line. I don't know the order those
are parsed in then.
>> 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.
oh. another user-error, I failed to read the comments enough to figure
out what was going on.
seph
