STINNER Victor <[email protected]> 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 <[email protected]> <http://bugs.python.org/issue12105> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
