Re: [PATCH] add new prctl for a per process wide close on exec V.3

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Oct 27, 2013 at 12:48:06PM +0100, Stefani Seibold wrote:
> This small patch adds a runtime prctl config option for a per process
> "close on exec" without breaking existing code.
> 
> With this feature a developer can decide if the application will pass all non
> "close on exec" file descriptors to a new process or not.
> 
> The mode of the process wide "close on exec" can be set with PR_SET_CLOEXEC and
> PR_GET_CLOEXEC returns the current mode. Mode is one of the following:
> 
> - PR_CLOEXEC_DEFAULT closes only the fd's marked as "close on exec" in
>    the child process, this is the linux default behaviour.
> 
> - PR_CLOEXEC_ONCE closes all fd's expect 0, 1 and 2 which are regular
>    handled as in PR_CLOEXEC_DEFAULT and reset the mode of the child to
>    PR_CLOEXEC_DEFAULT.
> 
> - PR_CLOEXEC_INHERIT is like PR_CLOEXEC_ONCE, but the mode will stay in the
>    child
> 
> STDIO file descriptors will be passed to the child process depending on the
> ..._CLOEXEC flag. So the new modes should be compatible to regular code.
> 
> This patch will increase security since no developers can review all libraries
> which there are using. Also in a team of developers it is not always possible
> to have a full survey over the code which is produced. Or the output of a code
> generators and so one. This patch allows a kind of preventive measures.
> 
> It can also prevent resource occupation. Imagine a long running process (a
> daemon) is execute from the application after open some file desciptors. For
> example libpcsclite.so will not open the socket with SOCK_CLOEXEC. Or a device
> driver which alows only a single open. In both cases the resource cannot
> reopened after a close. Sigh!
> 
> The usage is very simple:
> 
> if (prctl(PR_SET_CLOEXEC, PR_CLOEXEC_INHERIT, 0, 0, 0)) {
> 	perror("PR_SET_CLOEXEC");
> 	exit(1);
> }
> 
> If the prctl PR_SET_CLOEXEC was missused in a library, the caller will
> fail!

NAK.  All your arguments about Big Bad Wolf^WLibrary leaking opened files
through execve() are completely missing that possibility that "proactive"
program using this kludge might be linked against a Big Bad Library that
spawns a process and expects close-on-exec to work as designed.

And if execve() is in your program and under your control and you worry about
library-opened descriptors leaking through execve(), something like
unshare(CLONE_FILES | CLONE_CLOSEALL) before execve() would be a much