LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@linux-foundation.org,
	Christian Brauner <christian@brauner.io>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]
Date: Thu, 16 May 2019 17:31:30 +0100	[thread overview]
Message-ID: <20190516163130.GC17978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190516162259.GB17978@ZenIV.linux.org.uk>

On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote:
> On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote:
> > 
> > Hi Linus, Al,
> > 
> > Here are some patches that make changes to the mount API UAPI and two of
> > them really need applying, before -rc1 - if they're going to be applied at
> > all.
> 
> I'm fine with 2--4, but I'm not convinced that cloexec-by-default crusade
> makes any sense.  Could somebody give coherent arguments in favour of
> abandoning the existing conventions?

To elaborate: existing syscalls (open, socket, pipe, accept, epoll_create,
etc., etc.) are not cloexec-by-default and that's not going to change,
simply because it would be break the living hell out of existing userland
code.

IOW, the userland has to worry about leaking stuff over sensitive execve(),
no matter what.  All this change does is complicate things for userland
programmer - which syscall belongs to which class.

Where's the benefit?  I could buy an argument about gradually changing
over to APIs that are cloexec-by-default across the board, except for
the obvious fact that it's not going to happen; not with the things
like open() involved.

  reply	other threads:[~2019-05-16 16:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 11:52 David Howells
2019-05-16 11:52 ` [PATCH 1/4] uapi, fs: make all new mount api fds cloexec by default " David Howells
2019-05-16 11:52 ` [PATCH 2/4] uapi, fsopen: use square brackets around "fscontext" " David Howells
2019-05-16 11:52 ` [PATCH 3/4] uapi, x86: Fix the syscall numbering of the mount API syscalls " David Howells
2019-05-16 13:01   ` Christian Brauner
2019-05-16 11:52 ` [PATCH 4/4] uapi: Wire up the mount API syscalls on non-x86 arches " David Howells
2019-05-16 13:01   ` Christian Brauner
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:59     ` Christian Brauner
2019-05-16 16:22 ` [PATCH 0/4] uapi, vfs: Change the mount API UAPI " Al Viro
2019-05-16 16:31   ` Al Viro [this message]
2019-05-16 16:31   ` Christian Brauner
2019-05-16 16:50     ` Al Viro
2019-05-16 17:01       ` Christian Brauner
2019-05-16 20:23       ` Dmitry V. Levin
2019-05-17  6:54         ` Christian Brauner
2019-05-17  7:01       ` Christian Brauner
2019-05-17  7:13       ` David Howells
2019-05-17  7:25         ` Miklos Szeredi
2019-05-17  7:27         ` Christian Brauner
2019-05-16 18:57 Alexey Dobriyan

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=20190516163130.GC17978@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).