2013/1/13 Charles-François Natali :
>> .. 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* surprising, are
On 17/01/2013 13:02, Victor Stinner wrote:
2013/1/13 Jeff Allen:
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 proba
2013/1/13 Jeff Allen :
> 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 constructors, such as _io
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 o
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 exe
2013/1/14 Nick Coghlan :
> 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 (with no way to
On Mon, Jan 14, 2013 at 9:23 PM, Victor Stinner
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 the
>> child p
On Mon, Jan 14, 2013 at 9:23 PM, Victor Stinner
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 the intersection of t
Hi,
Thanks for your feedback, I already updated the PEP for most of your remarks.
2013/1/13 Charles-François Natali :
> Also, ISTM that Windows also supports this flag.
Yes it does, see Appendix: Operating system support > Windows.
>> .. note::
>>OpenBSD older 5.2 does not close the file de
On Mon, Jan 14, 2013 at 8:06 AM, Greg Ewing 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 compatibility issue is
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 clo
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 th
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.
I
> 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 fla
On Sun, 13 Jan 2013 23:49:32 +1000
Nick Coghlan 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 let us even
On Sun, Jan 13, 2013 at 11:22 PM, Antoine Pitrou wrote:
> On Sun, 13 Jan 2013 22:44:06 +1000
> Nick Coghlan wrote:
>> On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou wrote:
>> > As for the opacity, feel free to propose something better
>> > ("close_on_spawn", whatever). But I'm definitely and st
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou 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 quit
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou 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 the user s
On Sun, 13 Jan 2013 21:33:30 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou 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
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou 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 exec(), *not
On Sun, 13 Jan 2013 21:13:42 +1000
Nick Coghlan 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 coming
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
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 the
> chil
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
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
> definition/
On Sun, Jan 13, 2013 at 2:40 AM, Charles-François Natali
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
> definition/
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 P
> 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
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
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-January-2013
Python-Ver
27 matches
Mail list logo
