site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com Hi, -- Terry _______________________________________________ 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 Mar 21, 2008, at 12:42 AM, John D. wrote: 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). This email sent to site_archiver@lists.apple.com