site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com On Mar 21, 2008, at 5:08 PM, John D. wrote: goes something like this... (untested, of course:-) struct vnode_attr vattr; VATTR_INIT(&vattr); VATTR_WANTED(&vattr, va_mode); err = vnode_getattr(vp, &vattr, vfs_context_current()); Thanks. I figured it out also after reading the auditing related sources. I had some issues before I found out that you can couple multiple VATTR_WANTED calls :) I'm not sure on what's the best policy here, if I should start a new thread for some kauth related questions. I'm trying to implement a vnode scope listener that catches binary executions but so far I've only got a fileop scope listener to catch those properly. Maybe I'm simply doing something wrong. I was receiving NULL dvp (parent vnode) structures, which is impossible if we are executing a binary (ie. it must have a parent vnode, be it the root directory or the immediately top directory where the binary image / mach-o object is located). = 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... On Sat, Mar 22, 2008 at 12:27 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote: For trivial things like va_mode, you will typically be OK, but you should make a habit of checking VATTR_IS_SUPPORTED() for a field before using it, as some attributes aren't universal and can't be faked up for you by the VFS. If you don't have any fallback code you can just test VATTR_ALL_SUPPORTED() and fail if it returns false. The dvp is only set for KAUTH_SCOPE_VNODE listeners when the operation being authorised has a dependency on an explicit parent (since vnodes can have an arbitrary number of parents, including zero). Currently, this is only the case for DELETE. It is nontrivial to establish the set of parent objects that a vnode has (many filesystems don't store node parent information), so your design should as a rule avoid making any assumptions about node parentage. This email sent to site_archiver@lists.apple.com