William A. Rowe, Jr. wrote:
Brian Havard wrote:
I haven't been following this much but I gather we're trying to stop
child processes inheriting file handles they're not supposed to. Is
that it?
Yes; also our ABI implied, and now requires (in 1.3.0) that all three std
handles will be inherited, either explicitly, or default if none was
given.
UNLESS they use io_set with the new NO_FILE flag!
Ok, I'll check out what's going on with std handles next.
As it stands, your include/arch/os2/apr_arch_inherit.h doesn't
compile and when I tweaked it to do so, sockets.c fails to compile
because it was also using APR_IMPLEMENT_INHERIT_SET/UNSET and OS/2
sockets don't have a filedes.
Sorry for the typos; about the sockets, hmmm. Thinking.
Can we just make an alternate #ifdef OS2 flavor of the sockets inherit
impelementation stubs that don't touch fd's?
I think the APR_IMPLEMENT_INHERIT_SET/UNSET macros aren't useful here,
they're only useful when the same code can be used on different types.
On OS/2, files & sockets can just have their own implementations of
apr_*_inherit_[un]set(). There's a separate sockets.c for OS/2 so no
#ifdefs required.
I'll knock up a patch for making apr_file_open() open files
non-inheritable by default.
That is truly the best solution, it respects the laws of unintended
consequences on threaded servers.
Ok, doing that now.
Is it possible to dup-handle-to-process so we can dup-and-feed a series
of additional handles at a child? (Not sockets, apparently ;-)
Yeah, I guess so.
