Re: Does waitUntilExit really mean that?
Re: Does waitUntilExit really mean that?
- Subject: Re: Does waitUntilExit really mean that?
- From: Gwynne Raskind <email@hidden>
- Date: Tue, 14 Apr 2009 11:13:14 -0400
On Apr 14, 2009, at 4:03 AM, Uli Kusterer wrote:
FWIW, I was having some strange issues with NSTask and setuid child
processes (...) My eventual solution was to roll my own version of
NSTask which gave me full control over the way the child process
was set up, (...) I was able to track down the issue I was having
with the setuid process once I had the ability to trace the code
running between fork() and execve().
Care to elaborate on what NSTask is doing differently from your
solution and what difference this makes (in general and in your
particular use case)? Did you just hit an edge case, or is there
some fundamental problem that's likely to bite others? Did you file
a bug with Apple about this?
It turned out that the problem that was biting me was an extreme edge
case which really had less to do with NSTask's implementaion than the
fact that I couldn't step through its source code. The problem
actually turned out to be in the way the subprocess I was launching
was initializing itself, but until I was able to trace the codepath of
the child process - after fork(), before exec() - I wasn't able to
determine that.
The subprocess in question is one of those cross-platform programs
that tries to sandbox itself in a way that works on "any UNIX or
Windows OS", and generally ends up making a tremendous mess of other
processes that try to make use of it.
The major implementation differences between my version and the
standard NSTask seem to be in two categories: How I know the child
process successfully exec()d (NSTask uses kqueue() with EVFILT_PROC/
NOTE_EXEC, I use a data pipe), and how I manage the descriptor table
(NSTask uses CFFileDescriptor, I use POSIX-level system calls with
NSPipe/NSFileHandle). Also, I use a separate thread calling waitpid()
to raise the task termination notification.
One reason I stuck with my version of NSTask once I'd determined that
the culprit was actually the subprocess was that I was then able to
subclass it to create an NSPrivilegedTask using Security.framework and
all of the same NSTask API I'd already reimplemented. Since the real
NSTask's details are all squirreled away behind closed-source and
class clustering (NSTask = NSConcreteTask), it wasn't possible to
simply sublcass Apple's thing. And
AuthorizationExecuteWithPrivileges() can be kind of painful for those
who need finer control over the privileged code being executed (no
stderr pipe, no PID returned to parent, no control of child process
environment). Also, while perusing the open-source bits of
Security.framework, which thankfully include both AEWP() and the
trampoline it uses, I found some questionable security practices which
I was able to avoid in my own version. Yes, I did file Radars about
these issues.
I know AEWP() is extremely don't-use-this-without-
REALLYGOODREASON!!!!, and that any replacement must fall under the
same criteria. My version does, yes, allow you to shoot yourself in
the foot with security holes. It also allows you to close some that
AEWP() doesn't.
I'm planning to publish all my utility code, including my versions of
NSTask and the NSPrivilegedTask, under an open-source license, so
eventually I figure people will knock me over the head if I'm barking
up the wrong tree entirely :).
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden