site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On May 11, 2005, at 6:06 AM, Quinn wrote: At 14:55 +0200 11/5/05, Nicolas Berloquin wrote: Is this completely undocumented, or did I miss a piece of doc ? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... One more question, though : Is it possible to have more specific informations about the auth request, like the real VNOP that was issued and which generated the request ? Not as far as I know. Authorisation happens above, not below the VNOP layer. There's no way of obtaining any sort of "why am I being called" information; authorisation is limited to the actions. This prevents inconsistencies from cropping up if more sources of decisions are added later; the scope of the decision is completely defined. Note that you can get a request with more than one action defined in the vnode scope; this is why they're bitmasked. vnode_if.h lists all kinds of VNOPs that seem to be more finegrained than the bits passed to the callback. I logged the bitfield for each call, and I wasn't able to see when a file gets created for example... You should have seen a write authorization request for the parent directory. However, I should stress that (apart from for the KATH_SCOPE_FILEOP), Kauth is not a notification mechanism, it's an authorization mechanism. Hence you get information about the action being authorized, not the higher-level operation that caused it. Also note that there's no guarantee that there will be an authorisation request for every operation. If a particular credential is granted SEARCH permission on a directory, it may perform many lookups in that directory without the callback being invoked for every one. Be careful with KAUTH_SCOPE_FILEOP too; handlers must behave very cautiously in this scope. In particular, they must not block behind anything that may involve filesystem or paging activity (this includes roundtripping to userspace). One last thing : You say that "There are many other things you can use with VATTR_WANTED." It's not documented, per se, but there's a list in the <sys/ vnode.h> header in the Kernel framework. ... If you look at the VATTR_WANTED macro, you'll see that it ends up referencing these constants by concatenating VNODE_ATTR_ and its argument (eg va_nchildren). These correspond to the field names in the vnode_attr structure; you don't need to stare at those definitions, just look at the structure. This email sent to site_archiver@lists.apple.com