Re: Using fcntl from NKE
Re: Using fcntl from NKE
- Subject: Re: Using fcntl from NKE
- From: Quinn <email@hidden>
- Date: Fri, 18 May 2007 10:11:52 +0100
At 12:10 -0700 17/5/07, Mick Ring wrote:
According to Apple documentation, I only need com.apple.kernel.bsd
and com.apple.kernel.mach in order to use the headers in /sys, which
is where you'll find fcntl.h.
You're building with the wrong headers. When building a KEXT, you
need to build with the headers from the Kernel framework. If you
build with the standard headers (in "/usr/include"), you get problems
like this.
For example, compare the following two files:
/usr/include/sys/fcntl.h
/System/Library/Frameworks/Kernel.framework/Headers/sys/fcntl.h
The former has a prototype for the "fcntl" function:
int fcntl(int, int, ...);
but the latter does not. That because this function isn't callable
from kernel code.
Because you're building with the wrong headers, the compiler isn't
seeing the problem and you're fortunate that the linker caught it (-:
Does the fact that fcntl is undefined mean that I can't use it in my kext?
Yes. fcntl works in terms of file descriptors, which are inherently
a user space construct. We provide no support for KEXTs to work with
file descriptors.
If I can't use it, is there another mechanism for getting the pid
from a socket_t?
For a socket, the SIOCSPGRP ioctl will get you the same result as the
F_GETOWN fcntl.
There's one big caveat here. Most folks who ask for this information
are using it for security purposes. However, this information isn't
secure. The owner of the socket can set it to whatever values they
want. And, by default, it's set to 0.
If you're using this for security, a better approach is to latch the
current process ID as the socket is created. Keep in mind, however,
that a socket doesn't have a single owner. The descriptor associated
with the socket can be passed around between processes (by
inheritance over fork and by descriptor passing), which means that A)
the socket can have multiple owners, B) the socket can have /no/
owners (if it's in transit across a UNIX domain socket), and C) the
process that created the socket may no longer exist.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden