Re: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze
Re: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze
- Subject: Re: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze
- From: Liviu Andron <email@hidden>
- Date: Mon, 26 Jan 2009 12:52:11 +0200
On Thu, Jan 22, 2009 at 11:33 AM, Terry Lambert
<email@hidden> wrote:
On Jan 21, 2009, at 12:43 PM, Liviu Andron wrote:
On Wed, Jan 21, 2009 at 9:05 AM, Terry Lambert <email@hidden> wrote:
On Jan 20, 2009, at 3:51 PM, Liviu Andron <email@hidden> wrote:
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.
You gave it a small timeout and your user space process failed to wakeup on the wait channel before this timout expired, so you got EWOULDBLOCK.
If you attach projects, attach them to the problem report, rather than mailing them to everyone.
-- Terry
Well, I discovered the problem: I was doing a sysctl call ( sysctl(CTL_KERN, KERN_PROC, KERN_PROC_PID) ) between the reading of the packet from kernel and the setsockopt call that releases the msleep wait in kernel. Without the sysctl call it doesn't block on the KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE accesses. Should I avoid other system calls beside sysctl (open, malloc and printf work, even if only open is a Section 2 man function) ? I didn't attach the code to the (some) bug report since the problem conditions changed.
I filed an enhancement request for a "open vnode vp in process q" function.
For anti-virus software that generally translates to having, for example, all of your virus patterns already loaded up and ready to go so when the kernel asks for one, you can respond immediately, without having to do explicit file I/O or anything.
Effectively, this means that you need to be aware of the locks which are held when you hit a kauth hook you are hooking, and with that knowledge, know that you can't contend them with calls your daemon makes, or you will deadly-embrace deadlock.
In this particular case, you are probably asking for a property of the process that your kernel module could already know the answer to and provide as input information to user space. In general, it's a bad idea to do things like making identity policy decisions based on information you have to retrieve.
If I'd need "identity policy decisions" I'd use previous thread answers, like:
"getting the application path in VnodeScopeListener"
The sysctl() interface is guaranteed to be more problematic than most, since it was actualy never designed to be used how it's grown to be used. Effectively, it does non-leaf-node locking, including using the funnel, because historically people have abused terminal OID elements as a means of passing parameters down to proc handler functions. This is true for almost everything in KERN_PROC, and is also true of anything that operates by fsid. Some people also use oid elements for address parameters (really a problem, given that some processes are 64 bit, and OID elements are defined to be integer values).
You can shoot your foot off other ways, of course, by making calls other than sysctl(); the most common method of hurting your foot when you build a two-part kauth kext + daemon like this is to forget to make your user space daemon immune to kauth callbacks: if you forget that, then your daemon makes a call which triggers a kauth request to your daemon which makes a call which triggers a request which ...
-- Terry
Thanks for your "extended" help !
_______________________________________________
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