From: Ulrich Drepper <drepper@redhat.com>
To: "linux-kern >> Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: For the almost 4-year anniversary: O_CLOEXEC again
Date: Sun, 28 Mar 2004 17:34:19 -0800 [thread overview]
Message-ID: <40677D1B.9060801@redhat.com> (raw)
The last time I commented about this was almost exactly 4 years ago.
And the problem is still not resolved.
The situation is this:
thread 1 thread 2
fd = open(...)
fork()
fcntl(fd, F_SETFD, FD_CLOEXEC)
execve()
Multi-threaded apps can use fork(). Requiring theese use of fork() to
syncronize with every other thread and every piece of code which they
use wrt to opening files is impossible. Likewise impossible is it to
change the default to FD_CLOEXEC by default.
Some (vocal) people requested to always use separate processes when
security sensitive files are opened, processes which then can be single
threaded. I find this hardly acceptable especially since it just
introduces additional problems. Just think about opendir() which just
opens the directory using open().
The proposed solution is simple and already implemented on some systems
(QNX, BeOS, maybe more). Beside the definition of O_CLOEXEC the
untested patch below should be all that's needed. It does *not* solve
the related problem of socket descriptors etc. I've no good idea for
those situations. It cannot be done through a per-thread switch which
decides whether newly allocated descriptors are CLOEXEC until further
notice since open() is a signal-safe interface. The signal handler code
might not be aware of this mode and create descriptors which are not
inherited. At least this little change can handle open().
I sincerely hope that this is not again answered with curses on POSIX
and its authors. POSIX is here to stay and we should do whatever is
possible to fix it.
--- fs/open.c 2004-03-13 21:16:11.000000000 -0800
+++ fs/open.c-ud 2004-03-28 15:43:23.000000000 -0800
@@ -938,11 +938,14 @@ asmlinkage long sys_open(const char __us
if (!IS_ERR(tmp)) {
fd = get_unused_fd();
if (fd >= 0) {
- struct file *f = filp_open(tmp, flags, mode);
+ struct file *f = filp_open(tmp, flags & ~O_CLOEXEC,
+ mode);
error = PTR_ERR(f);
if (IS_ERR(f))
goto out_error;
fd_install(fd, f);
+ if (flags & O_CLOEXEC)
+ set_close_on_exec(fd, 1);
}
out:
putname(tmp);
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
next reply other threads:[~2004-03-29 1:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-29 1:34 Ulrich Drepper [this message]
2004-03-29 3:14 ` For the almost 4-year anniversary: O_CLOEXEC again Davide Libenzi
2004-03-29 4:23 ` dean gaudet
2004-03-29 13:18 ` Jamie Lokier
2004-03-29 18:59 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40677D1B.9060801@redhat.com \
--to=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox