site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Yes, sorta. What is it that you are actually trying to do? -- Terry On Aug 15, 2008, at 9:24 AM, Tim Schooley <tim@sbdev.net> wrote: Just to answer my own question, I think I can get away with using kauth_getuid(). Is this an acceptable solution? Cheers, Tim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This will get the effective UID of the credential fron the current vfs_context associated with the current thread. This will be the same as the credential associated with the task in which that thread lives, unless some other thread in the task has subsequently performed an operation to change the task credential while the current thread was blocked somewhere, or unless the current thread is using per-thread credentials. If the current thread is a kernel thread, as in a thread in a driver, and the operation is a proxy operation, then it will get you a "root" equal to that of the kernel task (which is why we pass around vfs_context_t's). The whole area of credentials is rather intricately choreographed, and is/should be tied solely to authorization, and not so much about authenticatipn, authority, or nonrepudiation. It identifies the actor in an actor/object/action relationship, and persists once the kernel is entered until it exits again. This isn't generally well understood by most people, and I've been meaning to put together a "Where do baby credentials come from, and what do they do all their lives?"-type talk for a couple years now. I would probably have to call it something dry like "Mac OS X kernel security architecture", though. 8-). You actually probably don't want to know the UID, you probably are asking whether or not something should be allowed instead, which is a completely different question that should be asked a different way; the effective UID is rarely at all useful below the BSD system call layer, or to code outside that layer. The way to ask is to ask whether a given actor is allowed to perform the requested action on an object or objects, and you should generally limit yourself to inserting yourself at a particular check and, when asked, saying "allow"/"deny"/"I don't care". On Fri, 15 Aug 2008 16:47:20 +0100, Tim Schooley wrote: Any way of obtaining a uid_t from a task_t in a kernel extension? This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com