Bug#635192: glibc-bsd: please provide O_CLOEXEC
On Sat, Jul 23, 2011 at 10:49:03AM -0500, Jonathan Nieder wrote:
> Package: libc0.1-dev
> Version: 2.13-10
> Severity: wishlist
>
> Hi,
>
> FreeBSD gained an implementation for O_CLOEXEC in r219999 (Add
> O_CLOEXEC flag to open(2) and fhopen(2), 2011-03-25), which made its
> way to the freebsd 8 branch in r220241 (MFC r219999, 2011-04-01).
> Here's a minimal patch (untested) to expose it along with some other
> constants from sys/fcntl.h.
>
> I'd prefer to find a way to make use of the sys/fcntl.h header
> directly to avoid having to chase changes like this, but the
> infrastructure doesn't seem to be available for that.
>
> No O_SEARCH yet, since kFreeBSD doesn't seem to implement it.
>
> 2011-07-23 Jonathan Nieder <jrnieder@gmail.com>
>
> * bits/fcntl.h: Define O_EXEC, O_TTY_INIT, O_CLOEXEC, and O_DIRECTORY,
> guarded by __USE_XOPEN2K8. Values are from sys/sys/fcntl.h of FreeBSD
> 9-current.
> * bits/fcntl.h: Do not require __USE_GNU as a condition for defining
> O_NOFOLLOW. Make the condition __USE_XOPEN2K8 instead since the flag
> is defined in that standard.
>
> diff --git i/bits/fcntl.h w/bits/fcntl.h
> index 7641626a..8669c9ae 100644
> --- i/bits/fcntl.h
> +++ w/bits/fcntl.h
> @@ -47,9 +47,7 @@
>
> #ifdef __USE_GNU
> # define O_DIRECT 0200000 /* Direct disk access. */
> -enum { O_DIRECTORY = 0 }; /* Must be a directory. */
> enum { O_NOATIME = 0}; /* Do not set atime. */
> -# define O_NOFOLLOW 0400 /* Do not follow links. */
> #endif
>
> #ifdef __USE_BSD
> @@ -65,6 +63,14 @@ enum { O_NOATIME = 0}; /* Do not set atime. */
> # define O_RSYNC O_SYNC /* Synchronize read operations. */
> #endif
>
> +#ifdef __USE_XOPEN2K8
> +# define O_EXEC 01000000 /* Open without read or write access. */
> +# define O_TTY_INIT 02000000
> +# define O_CLOEXEC 04000000
> +# define O_DIRECTORY 0400000 /* Must be a directory. */
> +# define O_NOFOLLOW 0400 /* Do not follow links. */
> +#endif
> +
> /* Since 'off_t' is 64-bit, O_LARGEFILE is a no-op. */
> #define O_LARGEFILE 0
>
I don't think we want such a patch right now, unless we also provide
modify the open function to call fcntl() with FD_CLOEXEC as a fallback.
Otherwise code is going to start using O_CLOEXEC, and leak file
descriptors on old kernel (with old being the kernel we ship). The
fallback is not racy, but should catch most of the cases.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: