• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Security - Write to protected directory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security - Write to protected directory


  • Subject: Re: Security - Write to protected directory
  • From: Michael Nickerson <email@hidden>
  • Date: Mon, 27 Oct 2008 17:43:14 -0400


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.


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.


--------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


_______________________________________________

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


  • Follow-Ups:
    • Re: Security - Write to protected directory
      • From: "Michael Ash" <email@hidden>
References: 
 >Security - Write to protected directory (From: Kelly Graus <email@hidden>)
 >Re: Security - Write to protected directory (From: Nick Zitzmann <email@hidden>)
 >Re: Security - Write to protected directory (From: Kelly Graus <email@hidden>)
 >Re: Security - Write to protected directory (From: "Michael Ash" <email@hidden>)
 >Re: Security - Write to protected directory (From: Tommy Nordgren <email@hidden>)
 >Re: Security - Write to protected directory (From: "Michael Ash" <email@hidden>)
 >Re: Security - Write to protected directory (From: Michael Nickerson <email@hidden>)
 >Re: Security - Write to protected directory (From: "Michael Ash" <email@hidden>)

  • Prev by Date: Re: Core Data Questions--Relationships, UUIDs, and Dirty States
  • Next by Date: Re: LSSharedFileList API bug(s) -- workaround?
  • Previous by thread: Re: Security - Write to protected directory
  • Next by thread: Re: Security - Write to protected directory
  • Index(es):
    • Date
    • Thread