[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: svn commit: r584943 - /apr/apr/trunk/include/arch/os2/apr_arch_inherit.h
From:       Brian Havard <brianh () kheldar ! apana ! org ! au>
Date:       2007-10-30 22:09:56
Message-ID: 4727B99B.5000800 () kheldar ! apana ! org ! au
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]