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: Terry Lambert <email@hidden>
- Date: Fri, 21 Mar 2008 19:06:17 -0700
On Mar 21, 2008, at 12:42 AM, John D. wrote:
Hi,
I'm new on the list, hopefully I'll contribute and help around as
much as I can. That said, I have a few issues with some code I'm
working on.... ;(
I would like to know how to access the mode of a file system object
(in this case, a directory) with only its vnode.
I don't have access out of the box to any vfs context nor extra data
besides the vnode alone.
I believe I can retrieve an usable vfs context using
vfs_context_current(), and then use vfs_getattr() but I can't figure
out how exactly they should be used. I tried looking for FreeBSD
specific documentation and reading the source a couple times, but
looks like I might be missing some macro to initialize the ctx or
attr variables.
Also, is there any function or macro to verify if a memory address
is contained within the user-land stack address space?
Any cryptographic (specifically, hashing) functionality already
implemented on kernel-land? (ie. if I wanted to calculate a SHA-256
of some in-kernel data).
Generally, this information is intentionally difficult to obtain,
since we do not want you compositing permissions on your own.
The security model is that you have an actor (a vfs_context_t), and
action (the operation to perform), and an object (in this case, the
vnode on which you wish o perform the action). Then you use an
authorization functions to ask if the specified actor is permitted to
perform the specified action on the specified object.
It's wrong for you to composite your own idea of whether or not an
action will be permitted, since your decision may not match the
decision of the system, nor of any MAC modules which may be loaded -
such as SeatBelt or MCX. It also will not take into account non-POSIX
style permissions which may or may not be present on the object (ACLs,
and so on), for which it is practically impossible for you to get an
answer without a hook into whatever security association vended your
credential in the first place (Directory Services in 10.5, "memberd"
in 10.4).
It is almost always better to make a kauth call instead and ask "can
actor do this class of action to this object?".
As things go forward, this will continue to tighten up, to the point
where it will be impossible to composite your own permissions, since
we will simply not provide KPI for you to get the raw permissions in
the first place (this is already true for certain group membership
operations, and is true for ACLs).
-- Terry
_______________________________________________
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