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: Terry Lambert <email@hidden>
- Date: Thu, 22 Jan 2009 01:33:19 -0800
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.
You don't want to have your user space daemon make any calls that take
any locks that are already held by the code path in your kauth
module. If you do, then you are pretty much guaranteed to deadlock.
You basically want to have the answers to all possible questions your
kauth module in the kernel is going to ask the user space portion in
hand and ready to go before it asks.
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.
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
_______________________________________________
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