[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] fts: fix cloexec races
From: |
Bruno Haible |
Subject: |
Re: [PATCH 1/2] fts: fix cloexec races |
Date: |
Mon, 14 Aug 2017 19:18:00 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-91-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
> (opendirat, diropen): Use O_CLOEXEC instead of set_cloexec_flag.
There are platforms which support O_CLOEXEC; on these platforms this commit
is an improvement (eliminate uncontrolled inheritance of fd if another thread
calls fork+exec()).
There are also platforms which don't support O_CLOEXEC; on these platforms
gnulib's fcntl.h substitute defines O_CLOEXEC to 0. So, adding it to
the open() or openat() arguments has no effect, and eliminating the
set_cloexec_flag is a regression: it introduces unwanted inheritance of fd
even in single-threaded programs.
Or did I miss something?
lib/popen-safer.c contains a helper function open_noinherit that
(a) is race-free on platformas which support O_CLOEXEC,
(b) prevents unwanted inheritance of fd in single-threaded programs.
How about
- moving this helper function to a separate module,
- adding a similar helper function for openat(),
- using these instead of unconditional uses of O_CLOEXEC ?
Alternatively, define O_CLOEXEC to a non-zero value on those platforms
that don't support it, and extend gnulib's open() and openat() wrappers
to support O_CLOEXEC. But this is more hairy because the platforms could,
at any time, introduce other O_* flags that happen to collide wit the value
we happen to pick for O_CLOEXEC.
Bruno