homepage

Story of O_CLOEXEC in the GNU libc, by Ulrich Drepper: "Secure File Descriptor Handling"
http://udrepper.livejournal.com/20407.html
--
> I could either add some voodoo configure checks to ensure
> that O_CLOEXEC is indeed supported
Hum, if I patch tempfile._mkstemp_inner() to use os.O_CLOEXEC if available, whereas this flag has no effect, the function will be less secure on Linux 2.6.22 (if the GNU libc exposes O_CLOEXEC).
Check O_CLOEXEC is configure is not safe if the host compiling Python uses a different kernel that the host running Python (e.g. think of Linux distro: Python is compiled on a different computer).
We need maybe a flag to indicate that O_CLOEXEC is supported by the running kernel or not. Or maybe a function to check it at least?
--
O_CLOEXEC was added to Ruby and then removed because the flag is sometimes ignored:
http://redmine.ruby-lang.org/issues/1291
http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/31643
"because boron chkbuild test result says, An old linux kernel ignore O_CLOEXEC silently instead of return an error. It may lead to bring new security risk. So, we have to be pending it until finish to implement proper fallback logic."
--
Read also the discussion about O_CLOEXEC on bugs-findutils mailing list:
"it's not a guarantee that the O_CLOEXEC actually had an effect"
Their patch uses :
static int
fd_is_cloexec (int fd)
{
 const int flags = fcntl (fd, F_GETFD);
 return (flags & FD_CLOEXEC) || (fcntl (fd, F_GETFL) & O_CLOEXEC);
}
static bool
o_cloexec_works (void)
{
 bool result = false;
 int fd = open ("/", O_RDONLY|O_CLOEXEC);
 if (fd >= 0)
 {
 result = fd_is_cloexec (fd);
 close (fd);
 }
 return result;
}
--
Oh, there is also SOCK_CLOEXEC, which may be useful for #5715.