clone.2, execve.2: Document interaction of execve(2) with CLONE_FILES

This patch the fact that a successful execve(2) in a process that
is sharing a file descriptor table results in unsharing the table.

I discovered this through testing and verified it by source
inspection - there is a call to unshare_files() early in
do_execve_common().

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Kevin Easton 2013-05-06 16:14:41 +10:00 committed by Michael Kerrisk
parent 3d350ba3c9
commit 8a76b19ecd
2 changed files with 8 additions and 0 deletions

View File

@ -203,6 +203,9 @@ or changes its associated flags (using the
.BR fcntl (2)
.B F_SETFD
operation), the other process is also affected.
If a process sharing a file descriptor table calls
.BR execve (2),
its file descriptor table is duplicated (unshared).
If
.B CLONE_FILES

View File

@ -202,6 +202,11 @@ The termination signal is reset to
.B SIGCHLD
(see
.BR clone (2)).
.IP *
The file descriptor table is unshared, undoing the effect of the
.B CLONE_FILES
flag of
.BR clone (2).
.PP
Note the following further points:
.IP * 3