Finder view of MacFUSE mounted volumes does not reflect access restrictions

[GoogleCodeExporter]

In Finder, for folders to which access is restricted, I expect to see: 

* 'no entry' icons against folders that I can neither open nor write to

* 'drop box' icons against folders that are -wx (write, execute) only

* 'no write' icon in the status bar at the bottom of the window when I'm 
reading a folder to which 
I can't write. 

The absence of these icons is noticeable: 

* using sshfs-static (within sshfs.app) from the command line

* with sshfs and ftp in MacFusion.

The .PNG attached compares two Finder views of the same directory: 

-- (above) volume mounted via afp
-- (below) volume mounted via sshfs.

Original issue reported on code.google.com by grahampe...@gmail.com on 30 Apr 2007 at 7:01

Attachments:

• [Finder windows do not indicate restrictions.png](https://storage.googleapis.com/google-code-attachments/macfuse/issue-164/comment-0/Finder windows do not indicate restrictions.png)

[GoogleCodeExporter]

MacFUSE 0.2.5
sshfs 0.2.0
MacFusion 1.01 beta
Mac OS X 10.3.9

Original comment by grahampe...@gmail.com on 30 Apr 2007 at 7:04

[GoogleCodeExporter]

Try using the 'noauthopaque' option. You have several choices in what types of 
access/permission mechanism 
you use with MacFUSE.

Original comment by si...@gmail.com on 30 Apr 2007 at 8:03

[GoogleCodeExporter]

> noauthopaque

No ACLs here; server is Mac OS X Server 10.3.9.

> types of access/permission mechanism

The restrictions are correct, it's just the Finder *window* that fails to 
iconise the restrictions.

grahamperrin:~ gjp22$ cd /Volumes/MacFUSE-issue-164/Groups/
grahamperrin:/Volumes/MacFUSE-issue-164/Groups gjp22$ ls -l
total 96
drwxrwx---   1 11690  1047   510 Mar  8 17:45 EPOCH
drwxrwx---   1 admin  1035    68 Mar  3  2004 ITS
-rw-r--r--   1 admin  admin    0 Feb 18  2005 NES
drwxrwxr-x   1 admin  1036   170 Jun 28  2005 New Enabling Services
drwxrwx---   1 20180  1044   544 Nov 15  2005 Sustain IT
drwxrwx---   1 21360  1038   340 Apr 26  2005 business strategy and the environm
drwxr-xr-x   1 admin  1030   204 Feb 13  2004 centrim
drwxr-xr-x   1 admin  1029   170 Jul  8  2003 freemancentre
drwxrwx---   1 6776   1032   238 Jul 27  2004 knowlaboration
dr-xr-xr-x   1 6776   1027   170 Jun 27  2003 knowledgeangels
dr-xr-xr-x   1 6776   1026   170 Jun 27  2003 lion
drwxrwx---   1 11690  1048   408 Apr  3 11:39 r0952-games
dr-xr-xr-x   1 6776   1028   170 Jun 27  2003 record

Original comment by grahampe...@gmail.com on 1 May 2007 at 5:51

[GoogleCodeExporter]

>> noauthopaque
>
> No ACLs here; server is Mac OS X Server 10.3.9.

Where did I say that 'noauthopaque' has to do with ACLs?

Original comment by si...@gmail.com on 1 May 2007 at 5:54

[GoogleCodeExporter]

<http://code.google.com/p/macfuse/wiki/CHANGELOG> 

> •   Support for Mac OS X Extended Security (Access Control Lists), new 
option: 'extended_security'.
> 
> Details: You can now pass the 'extended_security' option at
> mount-time to enable support for ACLs on a MacFUSE file system. The
> ACLs that you get are identical to those in HFS+, except that they
> are stored in Apple Double files instead of being stored in the HFS+
> attributes B-Tree. Of course, you can use the same commands ("chmod
> +a 'singh deny read'", "ls -le", etc.) to work with these ACLs. See
> the man page of chmod for details. IMPORTANT: If you want the kernel
> to honor these ACLs while accessing the file system, you also need
> to pass the 'noauthopaque' option at mount time. Without this
> option, the kernel will try to talk to the user-space daemon for
> authorizations. CAVEAT: The Apple Double files used to store ACLs
> have the default owner, group, permissions as a normal file would.

-- but your suggestion worked, thanks :-)

Last login: Tue May  1 06:52:27 on ttyp1
Welcome to Darwin!
grahamperrin:~ gjp22$ cd ~/Volumes/
grahamperrin:~/Volumes gjp22$ ls -l
total 0
drwx------   2 gjp22  staff  68 Apr 27 17:57 ndrive
drwx------   2 gjp22  staff  68 Apr 30 19:51 omnium
grahamperrin:~/Volumes gjp22$ sshfs gjp22@omnium.freeman-centre.ac.uk:/ 
~/Volumes/omnium -o 
noauthopaque -o volname=MacFUSE-issue-164

-- after which I see the expected icons. 

Re 
<http://groups.google.com/group/MacFusion-devel/browse_thread/thread/ea6ad6b4359
f5a4c> I'll add 
this to the list of options for which a GUI will be required. 

(Changelog was the first reference I found to noauthopaque -- sorry.)

Original comment by grahampe...@gmail.com on 1 May 2007 at 5:59

[GoogleCodeExporter]

Is there any reason why this option is off by default? 

I'm curious. 

Original comment by grahampe...@gmail.com on 1 May 2007 at 6:03

[GoogleCodeExporter]

extended_security requires noauthopaque for ACLs to be effective, but that 
doesn't mean noauthopaque can't be 
used otherwise. The FUSE API supports the access call, which a file system 
daemon can implement. If you want 
the call to go up to the daemon, you must have authopaque (that is, 
noauthopaque must not be provided). That's 
why it's not enabled by default.

Original comment by si...@gmail.com on 1 May 2007 at 6:13

[GoogleCodeExporter]

Okey dokey ... I'll digest that when I change from my pyjamas into my office 
clothes (!) but if -- as I suspect -- 
the option will be preferred by users who work predominantly in Finder, then a 
jargon-less explanation will be 
useful. 

Any volunteers? 

Thanks to all...

Original comment by grahampe...@gmail.com on 1 May 2007 at 6:27

[GoogleCodeExporter]

'noauthopaque' behavior will change in the next MacFUSE release, so I'd suggest 
not doing anything user-visible 
with it yet. I might just take it out and make its turning on/off 
automatic/adaptive based on the kind of user fs 
daemon.

Original comment by si...@gmail.com on 2 May 2007 at 5:26

• Changed state: WontFix

[GoogleCodeExporter]

Sounds good. Thanks.

Original comment by grahampe...@gmail.com on 3 May 2007 at 10:56

[GoogleCodeExporter]

Testing publicly with non-public MacFusion 1.01 Beta2. First impressions:

  * volumes mounted via SSHFS seem fine. 

  * a volume mounted via FTP for which I *appear* to have root credentials seems fine. 

(I don't intend to test an FTP connection to some other server where I have 
less than root privileges. I'm more 
of an SSHFS/SFTP person.)

I suggest a change of status to 
Verified

Thanks!

Original comment by grahampe...@gmail.com on 10 May 2007 at 9:28