2013/1/13 Charles-François Natali cf.nat...@gmail.com:
.. note::
OpenBSD older 5.2 does not close the file descriptor with
close-on-exec flag set if ``fork()`` is used before ``exec()``, but
it works correctly if ``exec()`` is called without ``fork()``.
That would be *really*
2013/1/13 Jeff Allen ja.@farowl.co.uk:
I think io, meaning _io and _pyio really, would be amongst the impacted
modules, and should perhaps be in the examples. (I am currently working on
the Jython implementation of the _io module.) It seems to me that io.open,
and probably all the
On 17/01/2013 13:02, Victor Stinner wrote:
2013/1/13 Jeff Allenja.@farowl.co.uk:
I think io, meaning _io and _pyio really, would be amongst the impacted
modules, and should perhaps be in the examples. (I am currently working on
the Jython implementation of the _io module.) It seems to me
On 01/14/2013 01:44 PM, Greg Ewing wrote:
I think protect is *far* too vague. We don't want something
so neutral that it gives no clue at all about its meaning.
My shoot-from-the-hip name suggestion: sterile. (Does not produce
offspring.)
When a process and a file descriptor love each
On 13/01/2013 00:41, Victor Stinner wrote:
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
Status: Draft
The PEP is still a draft. I'm sending it to python-dev to get a first review.
The main question is the choice between the 3 different options:
* don't set
On Mon, Jan 14, 2013 at 8:06 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
Agreed, but it's the security implications that let us even
contemplate the backwards compatibility break.
I don't think that's a sufficient criterion for choosing a
name. The backwards
Hi,
Thanks for your feedback, I already updated the PEP for most of your remarks.
2013/1/13 Charles-François Natali cf.nat...@gmail.com:
Also, ISTM that Windows also supports this flag.
Yes it does, see Appendix: Operating system support Windows.
.. note::
OpenBSD older 5.2 does not
On Mon, Jan 14, 2013 at 9:23 PM, Victor Stinner
victor.stin...@gmail.com wrote:
I'm not sure that it's so different than the change on subprocess
(close_fds=True by default on UNIX since Python 3.2). Do you think
that it would break more applications?
Don't ignore the possible explanation that
On Mon, Jan 14, 2013 at 9:23 PM, Victor Stinner
victor.stin...@gmail.com wrote:
XXX Should ``subprocess.Popen`` set the close-on-exec flag on file XXX
XXX descriptors of the constructor the ``pass_fds`` argument? XXX
What?
Setting them cloexec would prevent them from being inherited in
2013/1/14 Nick Coghlan ncogh...@gmail.com:
I'm a fan of the conservative approach, with an environment variable
and command line option to close FDs by default in 3.4 (similar to
PYTHONHASHSEED and -R in the pre-3.3 security releases), and the
cloexec/noinherit behaviour becoming the default
Nick Coghlan wrote:
The problem is the mechanism is *not the same* on Windows and POSIX -
the Windows mechanism (noinherit) means the file won't be accessible
in child processes, the POSIX mechanism (cloexec) means it won't
survive exec().
But since there is no such thing as a fork without
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
definition/prototype, whereas argument refers to the actual value
supplied).
This PEP
On Sun, Jan 13, 2013 at 2:40 AM, Charles-François Natali
cf.nat...@gmail.com wrote:
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
cf.nat...@gmail.com wrote:
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
cf.nat...@gmail.com wrote:
XXX Should ``subprocess.Popen`` set the close-on-exec flag on file XXX
XXX descriptors of the constructor the ``pass_fds`` argument? XXX
What?
Setting them cloexec would prevent them from being inherited
On Sun, 13 Jan 2013 21:13:42 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Also, ISTM that Windows also supports this flag. If it does, then
cloexec might not be the best name, because it refers to the
execve() Unix system call. Maybe something like noinherit would be
clearer (although
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
It also means we're free to implement a mechanism that tries to close
all sensitive file descriptors in _PyOS_AfterFork.
Ouch! This actually shows that noinherit is a very bad name. The PEP
is about closing fds after
On Sun, 13 Jan 2013 21:33:30 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
It also means we're free to implement a mechanism that tries to close
all sensitive file descriptors in _PyOS_AfterFork.
Ouch! This actually
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
(close_on_spawn, whatever). But I'm definitely and strongly -1
on noinherit.
That's the main reason I quite like sensitive as a term for this,
since it decouples
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
(close_on_spawn, whatever). But I'm definitely and strongly -1
on noinherit.
On Sun, Jan 13, 2013 at 11:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
On Sun, 13 Jan 2013 23:49:32 +1000
Nick Coghlan ncogh...@gmail.com wrote:
(it's not even just a security issue: letting a bound socket open and
therefore being unable to re-use the same port is a bug even when
security is not a concern)
Agreed, but it's the security implications that
Alternatives
Always set close-on-exec flag
-
Oops, this is completly wrong. This section is basically exactly the
same than the PEP proposal, except that the default value of cloexec
is set to True. The correct title is: Set the close-on-exec flag by
Nick Coghlan wrote:
Agreed, but it's the security implications that let us even
contemplate the backwards compatibility break.
I don't think that's a sufficient criterion for choosing a
name. The backwards compatibility issue is a transitional
thing, but we'll be stuck with the name forever.
On 1/13/2013 5:49 AM, Nick Coghlan wrote:
I agree it makes it obvious what the right default behaviour should
be: flag every FD as sensitive by default, and pass an argument to say
sensitive=False when you want to disable Python's automatic
protections.
sensitive is a bad name... because the
HTML version:
http://www.python.org/dev/peps/pep-0433/
***
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner victor.stin...@gmail.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
Status: Draft
The PEP is still a draft. I'm sending it to python-dev to get a first review.
The main question is the choice between the 3 different options:
* don't set close-on-exec flag by default
* always set
27 matches
Mail list logo
