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 -~----------~----~----~----~------~----~------~--~---
