I think will solve the problem I am having, on folders with XX0 permissions, I can't read them even when logged into the remote system as root.
On May 9, 12:00 am, Amit Singh <[EMAIL PROTECTED]> wrote: > MacFUSE 0.3.0 can do file permission check in 2 ways: > > 1. If the user-space file system program (such as sshfs-static, > curlftpfs, or whatever MacFusion might be using) actually implements a > permission check method (the "access" method), MacFUSE will call that > method to see if a given user has access to a given file. > > 2. If the user-space file system program doesn't implement an "access" > method, then MacFUSE will let your OS X kernel do permission check. > However, this relies on the user and group identifiers that are > reported by the user-space file system. Typically, your "local" user/ > group identifiers (on the Mac OS X client) are different from those on > your FTP or SSH server. For things to work correctly, the user-space > file system must then translate these remote identifiers to match the > local ones. Since it's not the kernel that's communicating with the > FTP/SSH servers, the kernel has no idea what the mapping is. If the > mapping is not there, or is incorrect, the kernel will think you're > trying to access somebody else's files, and you may get a permission > error. > > This leaves us with the case when the user-space file system neither > implements an "access" method, nor does user/group ID mapping. With > MacFUSE 0.3.0, if your local user/group ID happens to be different > from the remote one, you'll get a permission error for files/ > directories that don't allow the requested access to "others". This > isn't crazy or a serious problem--this is just how file systems work > in Mac OS X, or one version of how file systems work. > > One thing MacFUSE could do is to support an option (MacFUSE already > has a sickeningly large number of options, many of which end users > don't/shouldn't have to understand), say, "defer_auth". If this option > is specified at mount time, you're basically telling MacFUSE that you > *know* that you have a file system that neither maps user/group IDs, > nor implements "access". In that case, MacFUSE will provide a dummy in- > kernel version of access that just returns a 0 always (0 means the > permission is allowed). In this case, regardless of user/group ID > differences, file operations will go through, but they will still fail > (as they should) if you *really* don't have access on the server (that > is, if your FTP/SSH operation would fail through other FTP/SSH tools, > it would fail with MacFUSE; if the operation would succeed because you > really have access on the server, the operation would succeed with > MacFUSE). This can be thought of as a fallback mechanism. It was sort > of like this in MacFUSE release before 0.3.0, but there were some > subtle differences I'm too exhausted to explain at this moment. > > "defer_auth" will be in the next version of MacFUSE. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
