[Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks

[Ross Cohen]

On Sun, Jun 24, 2007 at 10:48:30PM +0200, "Martin v. Löwis" wrote:
> >> I don't see why it is a requirement to *open* the file in
> >> non-inheritable mode. Why is not sufficient to *modify*
> >> an open file to have its handle non-inheritable in
> >> an easy and platform-independent way?
> > 
> > Threads. Consider that you may fork a process on one thread right
> > between the calls to open() and fcntl(F_SETFD, FD_CLOEXEC) on another
> > thread. The only way to be safe is to open the file non-inheritable to
> > start with.
> 
> No, that's not the only safe way. The application can synchronize the
> threads, and prevent starting subprocesses during critical regions.
> Just define a subprocess_lock, and make all of your threads follow
> the protocol of locking that lock when either opening a new file,
> or creating a subprocess.

The problem here is that sitting in accept() becomes a critical section.
While a thread is sitting in that call, no other thread could start a
subprocess. A multithreaded server which uses a 1-thread-per-request
model wouldn't be possible, at least not in a reasonable amount of
comprehensible code.

> > Now, it is currently impossible under linux to open a file descriptor
> > noninheritable, but they're considering adding that feature (I don't
> > have the thread-refs on me, but it's actually from the last month). The
> > issue is that there's a *bunch* of syscalls that open FDs: this feature
> > would need to be added to all of them, not only "open".
> 
> Right. That is what makes it difficult inherently on the API level.

LWN has had good coverage of the discussion:
http://lwn.net/Articles/237722/

Ross