linux-kernel - Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190516163130.GC17978@ZenIV.linux.org.uk>
Date:   Thu, 16 May 2019 17:31:30 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     David Howells <dhowells@...hat.com>
Cc:     torvalds@...ux-foundation.org,
        Christian Brauner <christian@...uner.io>,
        Arnd Bergmann <arnd@...db.de>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

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.