[948] in athena10
Re: Permissions on /mit?
daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Jan 24 01:11:31 2009
Message-ID: <497AB0DE.7050104@mit.edu>
Date: Sat, 24 Jan 2009 01:10:38 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Brian Neltner <neltnerb@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <1232777290.4554.6.camel@gibbs-duhem>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
What do you get if you ls -l /dev/fuse?
- Evan
Brian Neltner wrote:
> Definitely not still mounted.
>
> /mit has permissions:
> drwxrwx--- 2 root pyhesiodfs 4096 2009-01-20 14:11 mit
>
> On Sat, 2009-01-24 at 01:06 -0500, Evan Broder wrote:
>
>> Are you sure that any other pyhesiodfs's that were running were
>> umounted? You can run `mount | grep pyhesiodfs` to confirm.
>>
>> And /mit is still owned root:pyhesiodfs with the permissions set to 775?
>>
>> - Evan
>>
>> Brian Neltner wrote:
>>
>>> neltnerb@belcher10:~$ cd /
>>> neltnerb@belcher10:/$ sudo -u pyhesiodfs /usr/bin/pyhesiodfs -f /mit/
>>> fusermount: mount failed: Operation not permitted
>>> Traceback (most recent call last):
>>> File "/usr/bin/pyhesiodfs", line 141, in <module>
>>> main()
>>> File "/usr/bin/pyhesiodfs", line 138, in main
>>> server.main()
>>> File "/usr/lib/python2.5/site-packages/fuse.py", line 713, in main
>>> main(**d)
>>> fuse.FuseError: filesystem initialization failed
>>>
>>> On Sat, 2009-01-24 at 00:59 -0500, Evan Broder wrote:
>>>
>>>
>>>> Hmm...try doing `cd /` and then `sudo -u pyhesiodfs /usr/bin/pyhesiodfs
>>>> -f /mit`
>>>>
>>>> - Evan
>>>>
>>>> Brian Neltner wrote:
>>>>
>>>>
>>>>> neltnerb@belcher10:~$ sudo -u pyhesiodfs /usr/bin/pyhesiodfs -f /mit
>>>>> fusermount: failed to open current directory: Permission denied
>>>>> Traceback (most recent call last):
>>>>> File "/usr/bin/pyhesiodfs", line 141, in <module>
>>>>> main()
>>>>> File "/usr/bin/pyhesiodfs", line 138, in main
>>>>> server.main()
>>>>> File "/usr/lib/python2.5/site-packages/fuse.py", line 713, in main
>>>>> main(**d)
>>>>> fuse.FuseError: filesystem initialization failed
>>>>>
>>>>> neltnerb@belcher10:/etc$ ls -l fuse.conf
>>>>> lrwxrwxrwx 1 root root 19 2009-01-24 00:22 fuse.conf ->
>>>>> fuse.conf.debathena
>>>>>
>>>>> neltnerb@belcher10:/etc$ ls -l fuse.conf.debathena
>>>>> -rw-r--r-- 1 root root 17 2008-11-20 19:30 fuse.conf.debathena
>>>>>
>>>>> neltnerb@belcher10:/etc$ cat fuse.conf
>>>>> user_allow_other
>>>>>
>>>>> On Sat, 2009-01-24 at 00:54 -0500, Evan Broder wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Well, I'm not sure, but this is only a temporary fix. For starters, you
>>>>>> were running pyhesiodfs as root instead of as the pyhesiodfs user. What
>>>>>> if you kill that session with `sudo umount /mit` and then run `sudo -u
>>>>>> pyhesiodfs /usr/bin/pyhesiodfs -f /mit`?
>>>>>>
>>>>>> Was anything printed out to the window you ran pyhesiodfs from?
>>>>>>
>>>>>> Oh - also, while we're at it, what are the contents of /etc/fuse.conf?
>>>>>>
>>>>>> - Evan
>>>>>>
>>>>>> Brian Neltner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Doing that allows me to add matlab and access /mit
>>>>>>>
>>>>>>> What changed by doing it this way?
>>>>>>>
>>>>>>> On Sat, 2009-01-24 at 00:42 -0500, Evan Broder wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> /mit is the only thing that should be chgrp'd to pyhesiodfs. What
>>>>>>>> happens if you run `sudo /usr/bin/pyhesiodfs -f /mit` in one window, and
>>>>>>>> then try to access something in /mit from another window?
>>>>>>>>
>>>>>>>> - Evan
>>>>>>>>
>>>>>>>> Brian Neltner wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> It looks like it is installed... I did aptitude purge of both
>>>>>>>>> debathena-pyhesiodfs and debathena-mit-automounter along with removing
>>>>>>>>> all of the other debathena-standard packages, but upon reinstalling it
>>>>>>>>> has the same behavior as before.
>>>>>>>>>
>>>>>>>>> Is there a way I can get it to report any errors that the automounting
>>>>>>>>> script returns? It is possible that some permissions on other files
>>>>>>>>> in /etc were changed that are causing difficulty, I accidentally changed
>>>>>>>>> a number of them to root:root, so if there were other files that were
>>>>>>>>> originally owned by pyhesiodfs or something else, that could cause a
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>> On Sat, 2009-01-24 at 00:10 -0500, Evan Broder wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> debathena-pyhesiodfs doesn't actually interact with AFS directly; it
>>>>>>>>>> gets locker information from Hesiod, so it should continue to work
>>>>>>>>>> regardless of whether or not AFS is working.
>>>>>>>>>>
>>>>>>>>>> Is there any chance that the debathena-pyhesiodfs package was
>>>>>>>>>> uninstalled somehow? What happens if you run `sudo aptitude install
>>>>>>>>>> debathena-pyhesiodfs`, just to make sure?
>>>>>>>>>>
>>>>>>>>>> - Evan
>>>>>>>>>>
>>>>>>>>>> Brian Neltner wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> This command returns nothing.
>>>>>>>>>>>
>>>>>>>>>>> It does have AFS on /afs type afs (rw) listed.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 2009-01-23 at 03:40 -0500, Evan Broder wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> When configured correctly, /mit is a FUSE filesystem, and all
>>>>>>>>>>>> attributes, including the owner and permissions of /mit itself, should
>>>>>>>>>>>> be controlled by the FUSE filesystem. The fact that yours is 770
>>>>>>>>>>>> root:pyhesiodfs instead of 755 root:root suggests that the /mit
>>>>>>>>>>>> automounter isn't running.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you get if you run `mount | grep pyhesiodfs`?
>>>>>>>>>>>>
>>>>>>>>>>>> - Evan
>>>>>>>>>>>>
>>>>>>>>>>>> Brian Neltner wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Dear Evan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I do that, I get this message again:
>>>>>>>>>>>>>
>>>>>>>>>>>>> neltnerb@belcher10:~$ sudo /etc/init.d/debathena-pyhesiodfs restart
>>>>>>>>>>>>> * Restarting Debathena /mit automounter debathena-pyhesiodfs
>>>>>>>>>>>>> [ OK ]
>>>>>>>>>>>>> neltnerb@belcher10:~$ cd
>>>>>>>>>>>>> neltnerb@belcher10:~$ renew
>>>>>>>>>>>>> Password for neltnerb@ATHENA.MIT.EDU:
>>>>>>>>>>>>> neltnerb@belcher10:~$ add matlab
>>>>>>>>>>>>> Cannot attach locker on /mit:
>>>>>>>>>>>>> directory /mit is group/other writable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> and permissions on the directory /mit are reset to:
>>>>>>>>>>>>>
>>>>>>>>>>>>> drwxrwx--- 2 root pyhesiodfs 4096 2009-01-20 14:11 mit
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there anywhere else that I might have permissions confused? Does my
>>>>>>>>>>>>> user need to be a member of group pyhesiodfs? Is something supposed to
>>>>>>>>>>>>> be run setuid somehow?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 2009-01-20 at 15:48 -0500, Evan Broder wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Brian -
>>>>>>>>>>>>>> It looks like the /mit automounter may not be running. Try running
>>>>>>>>>>>>>> `sudo /etc/init.d/debathena-pyhesiodfs restart`
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Evan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brian Neltner wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dear Tim et al,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm installing a server for my lab that I'd like to have set up so that
>>>>>>>>>>>>>>> people can use it to access their athena lockers and run athena software
>>>>>>>>>>>>>>> there (for instance gaussian) with X forwarding, as well as to access
>>>>>>>>>>>>>>> their personal athena directories.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've been able to do this successfully at home, but when I do this on
>>>>>>>>>>>>>>> the lab server, it gives me this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> neltnerb@belcher10:/$ renew
>>>>>>>>>>>>>>> Password for neltnerb@ATHENA.MIT.EDU:
>>>>>>>>>>>>>>> neltnerb@belcher10:/$ add matlab
>>>>>>>>>>>>>>> Cannot attach locker on /mit:
>>>>>>>>>>>>>>> directory /mit is group/other writable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I changed the permissions with chmod go-w /mit to remove the writable
>>>>>>>>>>>>>>> permissions and when I try again, it gives me this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> neltnerb@belcher10:~$ add matlab
>>>>>>>>>>>>>>> matlab: Could not attach locker:
>>>>>>>>>>>>>>> Permission denied while symlinking /afs/athena.mit.edu/software/matlab
>>>>>>>>>>>>>>> to /mit/matlab
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The folder /afs/athena.mit.edu/software/matlab exists and is readable by
>>>>>>>>>>>>>>> my normal user account.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The permissions right now on /mit look like this (after my
>>>>>>>>>>>>>>> modifications):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> drwxr-xr-x 2 root pyhesiodfs 4096 2009-01-20 14:11 mit
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My user account is not a member of pyhesiodfs, and I didn't try adding
>>>>>>>>>>>>>>> myself to that group because I don't know what it is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What are the permissions on /mit supposed to be?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Brian Neltner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
