Re: Accessing the mode of a directory with its vnode and other questions
Re: Accessing the mode of a directory with its vnode and other questions
- Subject: Re: Accessing the mode of a directory with its vnode and other questions
- From: Michael Smith <email@hidden>
- Date: Sun, 23 Mar 2008 21:24:03 -0700
On Mar 21, 2008, at 5:08 PM, John D. wrote:
On Sat, Mar 22, 2008 at 12:27 AM, Rick Macklem
<email@hidden> 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 :)
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.
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).
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden