Apple

On Sat, Jan 17, 2009 at 8:35 PM, Michael Smith <email@hidden> wrote:

The most likely cause of this problem is a deadlock; have you looked at what the vnode you're auth'ing is? Have you looked at what your process is doing?

= Mike

The vnode is the executable, of course: the one implied in KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE.

CommandLineUtility is the result of the "Standard tool" wizard in XCode (it prints a "Hello world" message). 35 is EWOULDBLOCK.

The name of the vnode is "/Users/Shared/CommandLineUtility/build/Debug/CommandLineUtility".

Jan 21 01:05:08 Livius-MacBook-Pro kernel[0]: scope=com.apple.kauth.vnode, action="" uid=501, vp=/Users/Shared/CommandLineUtility/build/Debug/CommandLineUtility, dvp=<null>

Jan 21 01:05:19 Livius-MacBook-Pro kernel[0]: msleep: 35 (312, bash (483), /Users/Shared/CommandLineUtility/build/Debug/CommandLineUtility)

Jan 21 01:33:59 Livius-MacBook-Pro kernel[0]: scope=com.apple.kauth.fileop, action="" uid=501, vnode=0x5ab8ea0, path=/Users/Shared/CommandLineUtility/build/Debug/CommandLineUtility

Jan 21 01:34:10 Livius-MacBook-Pro kernel[0]: msleep: 35 (9, CommandLineUtili (911), /Users/Shared/CommandLineUtility/build/Debug/CommandLineUtility)

My program does nothing beside setsockopt -> lck_mtx_lock, wakeup, _FREE.

The msleep looks like this:

struct timespec ts = { 15, 0 };

err = msleep(wait, NULL, PUSER, "wait for the result", &ts);

I can attach the projects. Is this ok (a common procedure) ?

On Jan 16, 2009, at 7:21 PM, Liviu Andron wrote:

1)
I try to process the requests from fileop & vnode scopes in user-mode, so the kernel module waits for the result from the user space application. Let's call the kernel module KauthORamaEx and the user mode application KauthORamaTest.

If I include the KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE file accesses in the process, KauthORamaTest blocks (cannot process these requests) until the msleep timeout expires (and, of course, the same happens for all the other requests in the meanwhile, resulting in temporary system freezes) . It blocks even if it does only the setsockopt call to release the request (resulting in a wakeup call in the kernel module).

KauthORamaEx is based on KauthORama sample, with the following additions:
- kern_control.h based user space communication (largely copied from http://developer.apple.com/documentation/Darwin/Conceptual/NKEConceptual/control/chapter_4_section_2.html)

- some single-liked tails (queue.h): clients (unit numbers for ctl_getenqueuespace and the PIDs for exclusion), waiting requests
- KauthORamaEx adds the request to the "waiting requests "queue and then waits for KauthORamaTest's answer

KauthORamaTest is also largely based on the same NKE sample code.

Reproduction, 10.5 and 10.6:
- load KauthORamaEx

- add one of the two scopes (Example: sudo sysctl -w kern.com_mycompany_kext_KauthORamaEx="add com.apple.kauth.vnode /usr/bin")

- start KauthORamaTest

- call less (/usr/bin/less)

When it doesn't reproduce:
- KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE accesses skipped

- KAUTH_VNODE_EXECUTE is combined with KAUTH_VNODE_ACCESS
- KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE accesses don't pass through msleep

- 10.4

Since Tiger has no problems, I suspect "/private/var/db/dyld/dyld_shared_cache_i386".

I can include the sample if needed.

2)
msleep related question: "Callers of this routine must be prepared for premature return, and check that the reason for sleeping has gone away"

In the sample above, I can check if the reason for return is the user space answer, but how can I see if it is the timeout exit ?
Is EWOULDBLOCK ok ?

3) KauthORama sample has 2 problems

- debug configuration panic on the line: "assert(*actionStrPtr != NULL)"
- it doesn't know about KAUTH_FILEOP_DELETE

Thanks in advance !

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
This email sent to email@hidden

References:
	>KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze (From: Liviu Andron <email@hidden>)
	>Re: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze (From: Michael Smith <email@hidden>)