Le Sun, 28 Jul 2013 12:18:55 +0200, Charles-François Natali <cf.nat...@gmail.com> a écrit : > 2013/7/28 Antoine Pitrou <solip...@pitrou.net>: > >> (C) Should we handle standard streams (0: stdin, 1: stdout, 2: > >> stderr) differently? For example, os.dup2(fd, 0) should make the > >> file descriptor 0 (stdin) inheritable or non-inheritable? On > >> Windows, os.set_inheritable(fd, False) fails (error 87, invalid > >> argument) on standard streams (0, 1, 2) and copies of the standard > >> streams (created by os.dup()). > > > > I have been advocating for that, but I now realize that > > special-casing these three descriptors in a myriad of fd-creating > > functions isn't very attractive. > > (if a standard stream fd has been closed, any fd-creating function > > can re-create that fd: including socket.socket(), etc.) > > > > So perhaps only the *original* standard streams should be left > > inheritable? > > Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to > a log file, a socket...) will likely break a lot of code, e.g. code > using os.system(), or code calling exec manually (and I'm sure there's > a bunch of it).
Hmm. os.exec*() could easily make standard streams non-CLOEXEC before calling the underlying C library function. Things are more annoying for os.system(), though. > Also, it'll be puzzling to have syscalls automatically set the cloexec > flag. I guess a lot of people doing system programming with Python > will get bitten, but that's a discussion we already had months ago... Perhaps this advocates for a global flag, e.g. sys.set_default_fd_inheritance(), with False (non-inheritable) being the default for sanity and security. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
