Re: Security - Write to protected directory
Re: Security - Write to protected directory
- Subject: Re: Security - Write to protected directory
- From: "Michael Ash" <email@hidden>
- Date: Mon, 27 Oct 2008 00:52:20 -0400
On Mon, Oct 27, 2008 at 12:07 AM, Michael Nickerson
<email@hidden> wrote:
>
> On Oct 24, 2008, at 10:46 PM, Michael Ash wrote:
>
>> On Fri, Oct 24, 2008 at 8:46 PM, Tommy Nordgren
>> <email@hidden> wrote:
>>>
>>> On 3 okt 2008, at 16.39, Michael Ash wrote:
>>>
>>>> ...snip
>>>
>>>> Nope! AEWP is a rather broken API in more ways than one. One of the
>>>> ways that it's broken is that it is *impossible* to correctly use it
>>>> without a subprocess which will cooperate with you. The reason for
>>>> this is that you *must* use wait4 or waitpid to reap the zombie that
>>>> will be created when the subprocess terminates, but AEWP provides *no*
>>>> way to get the pid. (You cannot use wait or wait3 because those could
>>>
>>> NOPE. As soon as the App terminates, any unreaped subprocess will
>>> become a child
>>> of, and finally reaped by launchd
>>
>> That's true, except it's bad form to leave zombies lying around when
>> your application has an unbounded lifetime, as basically every GUI
>> application does. It goes from bad to extremely bad if the
>> authorization process can be repeated an arbitrary number of times,
>> since you can build up an unlimited number of zombies that way. The
>> extreme difficulty of reaping the children left behind by AEWP is a
>> huge deficiency in the API.
>>
>
> You can always set things up to ignore child processes:
> signal( SIGCHLD, SIG_IGN );
It's bad to rely on this sort of global state, though. What if some
other bit of code relies on having a handler for this signal? (Of
course it is relying on this sort of global state too in that case,
but it takes two to screw things up....)
> That way, if the children aren't specifically reaped they don't stay around
> as zombies. Do note that the wait functions *do* still work if you set that
> up, so this isn't going to mess anything up elsewhere that is reaping a
> child.
How does that work, exactly? The whole purpose of the zombie is to
store the end state of the dead process so that wait() can pick it up.
If wait() still works, then what stores that end state if not a zombie
process? More to the point, if wait() still works, that implies that
*something*, *somewhere* is storing that end state. And if you never
call wait() but you continue to create children, that storage will
grow without limit, and this is bad. So it seems to me that either no,
wait() doesn't really work in this scenario, or in fact you still get
zombies or something like them. Am I missing something?
Mike
_______________________________________________
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