You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bojan Smojver <bo...@rexursive.com> on 2008/08/05 03:52:11 UTC
To O_CLOEXEC or not?
After reading this article on LWN: http://lwn.net/Articles/292559/, it
occurred to me that it may be useful to pass this flag to open in
apr_file_open() on platforms that support it, in case someone decides to
fork()/execve() by non-APR means.
Of course, apr_file_inherit_[un]set() would have to be modified
accordingly.
Comments?
--
Bojan
Re: To O_CLOEXEC or not?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2008-08-06 at 14:00 +1000, Bojan Smojver wrote:
> I was thinking something like this (untested).
Probably not complete. I guess we should check in file_cleanup() if the
error on close() is EBADF and not report it if O_CLOEXEC is defined. Or
something like that...
--
Bojan
Re: To O_CLOEXEC or not?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2008-08-05 at 14:57 -0500, William A. Rowe, Jr. wrote:
> You have it upside down though, apr_file_inherit_[un]set should toggle
> the CLOEXEC flag.
I was thinking something like this (untested).
--
Bojan
Re: To O_CLOEXEC or not?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
> On Tue, Aug 5, 2008 at 04:52, Bojan Smojver <bo...@rexursive.com> wrote:
>
>> Of course, apr_file_inherit_[un]set() would have to be modified
>> accordingly.
>>
>> Comments?
> By all means, the more default security measures are added, the better.
> However this would imply a jump to APR 2.x and a considerable effort
> for APR users.
You have it upside down though, apr_file_inherit_[un]set should toggle
the CLOEXEC flag.
Re: To O_CLOEXEC or not?
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On Tue, Aug 5, 2008 at 04:52, Bojan Smojver <bo...@rexursive.com> wrote:
> After reading this article on LWN: http://lwn.net/Articles/292559/, it
> occurred to me that it may be useful to pass this flag to open in
> apr_file_open() on platforms that support it, in case someone decides to
> fork()/execve() by non-APR means.
A project I worked on a while back supported external third party
plug-ins. Those plug-ins could, at any point decide to
fork()/execve(). I'm pretty sure this wasn't the only project of this
kind that used APR (do you know what the binary dbd's you link APR to
do?)
> Of course, apr_file_inherit_[un]set() would have to be modified
> accordingly.
>
> Comments?
By all means, the more default security measures are added, the better.
However this would imply a jump to APR 2.x and a considerable effort
for APR users.
--
Lucian