Hacking the OS X Kernel for Fun and Profiles

Re:Hacking the OS X Kernel for Fun and Profiles by mikeash on Tuesday August 13, 2013 @04:02PM (#6207909)

Well, the man page says otherwise, and I'd hate to rely on undocumented safety buried in the standard library.

Edit: upon re-reading the man page, this bit caught my eye:

"If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec yourself."

So that would be one (highly painful) way to handle this safely. Fork, then self-exec, passing in arguments that tell the newly execed process what you really want to run. The new process can then do the /dev/fd listing in peace, then call exec again. Eww.

[ Parent | on HN ]

Re:Hacking the OS X Kernel for Fun and Profiles by klodolph on Tuesday August 13, 2013 @04:20PM (#6208027)

Seems like you're right. Whoops, time to go fix some of my code, which is why I really want a non-broken posix_spawn().

Another silly way to do things is to have the parent process send a list of fds to close over a pipe, which at least doesn't require a second call to exec().

I think the problem with close-on-exec is always going to be simple though: you have to make sure every library you use sets the flag.

[ Parent | on HN ]

Re:Hacking the OS X Kernel for Fun and Profiles by bdash on Tuesday August 13, 2013 @04:33PM (#6208089)

OS X provides the POSIX_SPAWN_CLOEXEC_DEFAULT flag to posix_spawn, which results in it automatically closing all file descriptors that aren't described by the file actions passed to posix_spawn.

[ Parent | on HN ]