All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyle Evans <kevans@freebsd.org>
To: unlisted-recipients:; (no To-header on input)
Cc: Szabolcs Nagy <nsz@port70.net>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	torvalds@linux-foundation.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Victor Stinner <victor.stinner@gmail.com>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	linux-api@vger.kernel.org, fweimer@redhat.com, jannh@google.com,
	oleg@redhat.com, arnd@arndb.de, shuah@kernel.org,
	dhowells@redhat.com, ldv@altlinux.org
Subject: Re: [PATCH v5 1/3] open: add close_range()
Date: Fri, 5 Jun 2020 22:11:14 -0500	[thread overview]
Message-ID: <CACNAnaGKr2WMGhiXUb4_HVQCKwe5RH7fTNuRHuwCtbfnBK-gXQ@mail.gmail.com> (raw)
In-Reply-To: <CACNAnaEjjQBB8ieZH+td8jk-Aitg3CjGB1WwGQwEv-STg5Do+g@mail.gmail.com>

On Fri, Jun 5, 2020 at 9:54 PM Kyle Evans <kevans@freebsd.org> wrote:
>
> On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy <nsz@port70.net> wrote:
> >
> > * Christian Brauner <christian.brauner@ubuntu.com> [2020-06-02 22:42:17 +0200]:
> > > [... snip ...]
> > >
> > > First, it helps to close all file descriptors of an exec()ing task. This
> > > can be done safely via (quoting Al's example from [1] verbatim):
> > >
> > >         /* that exec is sensitive */
> > >         unshare(CLONE_FILES);
> > >         /* we don't want anything past stderr here */
> > >         close_range(3, ~0U);
> > >         execve(....);
> >
> > this api needs a documentation patch if there isn't yet.
> >
> > currently there is no libc interface contract in place that
> > says which calls may use libc internal fds e.g. i've seen
> >
> >   openlog(...) // opens libc internal syslog fd
> >   ...
> >   fork()
> >   closefrom(...) // close syslog fd
> >   open(...) // something that reuses the closed fd
> >   syslog(...) // unsafe: uses the wrong fd
> >   execve(...)
> >
> > syslog uses a libc internal fd that the user trampled on and
> > this can go bad in many ways depending on what libc apis are
> > used between closefrom (or equivalent) and exec.
> >
>
> Documentation is good. :-) I think you'll find that while this example
> seems to be innocuous on FreeBSD (and likely other *BSD), this is an
> atypical scenario and generally not advised.  You would usually not
> start closing until you're actually ready to exec/fail.
>

Minor correction: not innocuous here, either; O_CLOFORK is not yet a thing. :-)

  reply	other threads:[~2020-06-06  3:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 20:42 [PATCH v5 0/3] close_range() Christian Brauner
2020-06-02 20:42 ` [PATCH v5 1/3] open: add close_range() Christian Brauner
2020-06-02 23:30   ` Florian Weimer
2020-06-02 23:37     ` Christian Brauner
2020-06-03 10:24   ` Michael Kerrisk (man-pages)
2020-09-17  7:52     ` Michael Kerrisk (man-pages)
2020-06-05 14:55   ` Szabolcs Nagy
2020-06-06  2:54     ` Kyle Evans
2020-06-06  3:11       ` Kyle Evans [this message]
2020-06-06 11:55       ` Szabolcs Nagy
2020-06-06 14:43         ` Kyle Evans
2020-06-07 13:22     ` David Laight
2020-06-02 20:42 ` [PATCH v5 2/3] arch: wire-up close_range() Christian Brauner
2020-06-02 20:42   ` Christian Brauner
2020-06-02 20:42   ` Christian Brauner
2020-06-02 20:42   ` Christian Brauner
2020-06-02 20:42 ` [PATCH v5 3/3] tests: add close_range() tests Christian Brauner
2020-06-02 21:03 ` [PATCH v5 0/3] close_range() Linus Torvalds
2020-06-02 23:33   ` Christian Brauner
2020-06-03  0:08     ` Linus Torvalds
2020-06-03 23:24       ` Christian Brauner
2020-06-04  0:13         ` Linus Torvalds
2020-06-04  1:15           ` Christian Brauner
2020-06-07 12:31         ` David Laight

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=CACNAnaGKr2WMGhiXUb4_HVQCKwe5RH7fTNuRHuwCtbfnBK-gXQ@mail.gmail.com \
    --to=kevans@freebsd.org \
    --cc=arnd@arndb.de \
    --cc=christian.brauner@ubuntu.com \
    --cc=dhowells@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=jannh@google.com \
    --cc=ldv@altlinux.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nsz@port70.net \
    --cc=oleg@redhat.com \
    --cc=shuah@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=victor.stinner@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.