On Nov 4, 2:45 pm, Chris Frost <[EMAIL PROTECTED]> wrote:
> I am not quite convinced that macfuse should call fuse_access() to
> determine whether it can unlink a file, for a few reasons.
MacFUSE doesn't call it, the kernel does. The in-kernel system call
handler for unlink(2) calls the vnode_authorize() kernel function,
which, depending upon several factors, can call back into MacFUSE's
vnode-level access(), which will then call the user-space file system
if the latter implements access(). MacFUSE itself doesn't really know
why the kernel might be calling it.
The checks done by vnode_authorize() are much finer grained than what
access() permits (basically {F, R, W, X}_OK), but the FUSE API doesn't
know about the finer grained mechanism on OS X. I don't plan to extend
the FUSE API in an ad hoc manner--when I do, it'll probably have a lot
of platform-specific functionality.
> 2. It seems that a fuse daemon's fuse_access() response should be a function
> of whether the macfuse kernel module is doing permission checking or
A better approach would be to either not do authorization in the user-
space file system at all (let the kernel handle it based on metadata),
or use the hypothetical extended Mac OS X specific API that supports a
fine grained version similar to the kernel's.
> Fwiw, I am not sure what "reliable" means here. Are ACLs "reliable" and
> does a fuse file system implement ACLs checking through fuse_access()?
Reliable means there is sufficient and sufficiently correct security-
related metadata provided by the user-space file system so that the
kernel can make authorization decisions based on it. It doesn't have
to be ACLs--it can just be uid/gid and permissions information.
Suppose you wrote a file system that disallows all access to files
with inode numbers that are prime--the kernel doesn't know that, so
you'll need your own access(). Let me ask you this: why are you
implementing an access() in your user-space file system? Is there some
authorization decision that your file system alone can make and the
kernel couldn't make based on the getattr data you gave the kernel?
Why not use default_permissions, for example? The best part about not
doing your own access() method is the performance gain--as you'll
notice, if you do implement access() in your daemon, it gets called a
lot.
> I would enjoy reading why MacFUSE and Linux FUSE differ in this way.
I wouldn't enjoy writing about it though.
> I may need to think more about this to fully understand its interactions.
> But, access(foo, F_OK) when:
> - foo->foo returns ELOOP on MacOSX HFS+, but this returns 0
> - foo->does_not_exist returns ENOENT on MacOSX HFS+, but this returns 0
> Unless I am mistaken? I did not test the above code, just MacOSX HFS+.
Yes, it doesn't behave the same as HFS+. If you want to make
fusexmp_fh closer to how HFS+ behaves, you would *remove* xmp_access()
altogether. The idea is not to show how to mimic HFS+--the idea is to
show how to implement a bunch of file system methods.
It's not as bad as I think you're imagining. Remember that when
something needs to happen to a symlink *target* (read/write/permission
change, etc.), you will get access() calls for the *target*--so even
if you really /had/ to implement an access() method, you could just
always return a 0 for symlinks (no need to even check for ELOOP or
ENOENT). If your daemon gets a call for a path that's a symlink, the
kernel wants to know about the symlink, not the target.
> And there are other, not as relevant subtleties, like the sb.st_uid check
> (it is insufficient, and I believe ignores effective vs real permission
> differences for access(2) vs. operation permissions). I mention this point
> just to note that getting this code correct is kind of hard. So there's a
> decent chance that some fuse daemons will get it wrong.
That's why it's better for the daemons to not get involved in this,
*if possible*. HFS+ itself leaves it to the kernel and doesn't
implement a vnode-level access(). MacFUSE implements one so that *if
necessary*, a user daemon has the option of implementing one in user
space.
All said, a pragmatic thing to do could be for me to not send up any
access() calls for *symlinks* up to user space--just return 0
(success) in the kernel. That takes care of your problem and I can
remove the special casing in fusexmp_fh. Even though Mac OS X has
things like lchmod(3), permission checking on the symlink itself
shouldn't matter.
Amit
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
