[950] in athena10

home help back first fref pref prev next nref lref last post

Re: Permissions on /mit?

daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Jan 24 01:17:00 2009

Message-ID: <497AB227.1060809@mit.edu>
Date: Sat, 24 Jan 2009 01:16:07 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Brian Neltner <neltnerb@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <1232777564.4554.7.camel@gibbs-duhem>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hmm...what about /bin/fusermount?

- Evan

Brian Neltner wrote:
> neltnerb@belcher10:/$ ls -l /dev/fuse 
> crw-rw---- 1 root fuse 10, 229 2009-01-21 19:11 /dev/fuse
>
> On Sat, 2009-01-24 at 01:10 -0500, Evan Broder wrote:
>   
>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>>       
>>>>>>>>>>>>>>>>>           
>>>>>>>>>>>>>>>>>               
>>>>>>>>>>>>>>>>>                   
>>>>>>>>>>>>>>>>>                       
>>>>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>       
>>>>>>>>>>>>>>>           
>>>>>>>>>>>>>>>               
>>>>>>>>>>>>>>>                   
>>>>>>>>>>>>>>>                       
>>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>   
>>>>>>>>>>>>>       
>>>>>>>>>>>>>           
>>>>>>>>>>>>>               
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>   

home help back first fref pref prev next nref lref last post