On Tue, Aug 5, 2008 at 04:52, Bojan Smojver [EMAIL PROTECTED] 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()
Lucian Adrian Grijincu wrote:
On Tue, Aug 5, 2008 at 04:52, Bojan Smojver [EMAIL PROTECTED] 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
===
--- file_io/unix/open.c (revision 683098)
+++ file_io/unix/open.c (working copy)
@@ -125,6 +125,12 @@
oflags |= O_BINARY;
}
#endif
+
+#ifdef O_CLOEXEC
+if (!(flag APR_FILE_NOCLEANUP)) {
+oflags |= O_CLOEXEC;
+}
+#endif
#if APR_HAS_LARGE_FILES
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
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
