public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 ❖

             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