Well that'd certainly answers why allow_others changes things, instead of its metadata ops not returning properly its sending weird data. What process is actually sending those requests on behalf of Finder or is it actually the Finder process doing that?
Sam Moffatt http://pasamio.id.au On Wed, Apr 13, 2011 at 12:31 AM, Peter Stegemann <[email protected]> wrote: > Hi, > > I've done some more debugging and found that the MacFUSE gets calls to > fuse_vnop_getattr with "bad" request credentials. Whereas on 10.6 the request > credentials match fine with the daemon credentials. > > This is what I get on 10.7: > > uid=502, ruid=0, groups[0]=20, gid=0, svgid=0 > > And this is what is expected (by fuse_match_cred()): > > uid=502, ruid=502, groups[0]=20, gid=20, svgid=20 > > > I've also seen some calls with uid=0, ruid=0, groups[0]=0, gid=0, svgid=0 > that I haven't seen on 10.6, but they don't hurt operations, as > fuse_blanket_deny() is also checking vfs_context_pid() which saves the day > for that call. > > > So, is there an expert out there who knows _why_ fuse_match_cred() does what > it does (other than being a copy of the BSD version)? Or maybe somebody who > can judge what to change to make this work again (a simple hack to make it > work was easy, I'm talking about a reliable fix). > > Regards, > Peter > > -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" 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?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MacFUSE" 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?hl=en.
