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: Tue, 28 Oct 2008 12:01:50 -0400
On Mon, Oct 27, 2008 at 5:43 PM, Michael Nickerson <email@hidden> wrote:
>
> On Oct 27, 2008, at 12:52 AM, Michael Ash wrote:
>
>> On Mon, Oct 27, 2008 at 12:07 AM, Michael Nickerson
>> <email@hidden> wrote:
>>>
>>> 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....)
>>
>
> Libraries and frameworks shouldn't be setting or relying on signals. It is,
> as you say, a global state. So really, if you haven't specifically set it
> in your app, you should be fine and if you have you should already know
> about it.
True enough, but it limits the usefulness because you can't safely use
it in a framework or plugin.
>>> 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?
>>
>
> Sorry, my fault for replying late at night. The wait functions will still
> block for the duration of the child process, but you do lose the state
> information about it. So if you're relying on state information I suppose
> you would consider that broken, but if all you're using wait for is to wait
> until the child process has terminated, then it still works as intended.
Thanks for clarifying. Unfortunately this would then have the
potential to break other code, in frameworks or plugins, which relies
on wait() to return state information, so it seems like a dangerous
thing to use.
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