[issue12105] open() does not able to set flags, such as O_CLOEXEC
STINNER Victor
report at bugs.python.org
Mon May 23 13:19:14 CEST 2011
STINNER Victor <victor.stinner at haypocalc.com> added the comment:
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.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________
More information about the Python-bugs-list
mailing list