linux-kernel - Would adding closefrom(2) syscall to the kernel make sense ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20150603065532.GA12224@proliant.localnet>
Date:	Wed, 3 Jun 2015 08:55:32 +0200
From:	Xavier Roche <roche@...rack.com>
To:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Would adding closefrom(2) syscall to the kernel make sense ?

Hi folks,

Would a closefrom syscall (ie. close all fd above a certain fd) make sense in the kernel, or is this something deemed /undesirable/ ?
Zheng Liu submitted a patch some time ago (<1396941142-24821-1-git-send-email-wenqing.lz@...bao.com> ; (3)) to add this feature, but with minor code issues, and no followup was made.

Rationale:

Many real-life programs use fork()/exec() to spawn child, and, before calling exec(), use close() on all file descriptors above 3. This is typically used using closefrom() when available, or, when unavailable, through regular close() calls from fd=3 to fd=sysconf(_SC_OPEN_MAX)-1 (or by listing /proc/self/fd, and taking note of the highest fd).

The reason to close "all file descriptors above 3" is a pragmatic approach over the existing dirty universe, where almost everybody forget to clear the "close on exec" flag, leading to inherit fd in forked task.

Clearing the "close on exec" flag for all file descriptors is cumbersome enough for most programmers to forget to comply:
	open(..., ...) => open(..., ... | O_CLOEXEC)
	fopen(..., ...) => open(..., ... | O_CLOEXEC) + fdopen(...) OR fopen(..., ... + "e")
	dup(...) => fcntl(..., F_DUPFD_CLOEXEC, (long) 0)
	dup2(..., ...) => dup3(..., ..., O_CLOEXEC)
	opendir(...) => open(..., O_RDONLY | O_DIRECTORY | O_CLOEXEC) + fdopendir(...)
	pipe(...) => pipe2(..., O_CLOEXEC)
	acept(..., ..., ...) => accept4(..., ..., ..., O_CLOEXEC)
	socket(..., ..., ...) => socket(..., ... | SOCK_CLOEXEC, ...)
etc.

(some of the solutions listed are unavailable depending on the kernel version, glibc version, etc.)

This situation leads to thousands of useless close() syscall (see for example (4)), and a better solution might be desirable rather than relying on the hypothetic cleaning of the known universe.

Both BSD (2) and Solaris (3) support this feature, by the way. (I know, some people will consider this as a rebuttal to add this feature, but anyway)

(1) https://lwn.net/Articles/593778/
(2) http://www.unix.com/man-page/freebsd/2/closefrom/
(3) http://docs.oracle.com/cd/E26505_01/html/816-5168/fdwalk-3c.html
(4) https://bugs.openjdk.java.net/browse/JDK-4791640

Regards,
Xavier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/