Re: [RFC] Subtle race in dup2() and permissions on /proc/<pid>/fd/<n>

Guest section DW (dwguest@win.tue.nl)
Fri, 25 Jun 1999 03:39:20 +0200 (MET DST)


From viro@math.psu.edu Fri Jun 25 03:17:39 1999

On Fri, 25 Jun 1999, Guest section DW wrote:

> viro asks:
>
> > dup2(foo, bar) closes bar, but completely ignores the results of
> > close(). POSIX position on that?
>
> The call
> fd = dup2(fd1,fd2);
> is equivalent to
> close(fd2);
> fd = fcntl(fd1, F_DUPFD, fd2);

Ouch... Does it imply that for two threads sharing the descriptors (cloned
with COPY_FILES) dup2(foo, bar); and close(foo); may legitmately result in
both foo an bar closed?

Such things are not forbidden.

The Rationale says:

The dup2() function is not intended for use in critical regions as a
synchronization mechanism.

and

Least obvious is the possible effect of a signal-catching function that could
be invoked between steps and allocate or deallocate file descriptors.

In short - the details are implementation dependent.
The close will take time, and it may well be that it turns out that
afterwards fd1 does not exist anymore. I imagine that you return EBADF
in such a case.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/