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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 Mar 2019 09:00:58 -0800
From:   Linus Torvalds <>
To:     Aleksa Sarai <>
Cc:     Al Viro <>,
        Jeff Layton <>,
        "J. Bruce Fields" <>,
        Arnd Bergmann <>,
        David Howells <>,
        Eric Biederman <>,
        Christian Brauner <>,
        Kees Cook <>,
        David Drysdale <>,
        Andy Lutomirski <>,
        Andrew Morton <>,
        Alexei Starovoitov <>,
        Jann Horn <>, Chanho Min <>,
        Oleg Nesterov <>, Aleksa Sarai <>,,
        linux-fsdevel <>,
        Linux API <>,
        Linux List Kernel Mailing <>,
        linux-arch <>
Subject: Re: [PATCH RESEND v5 2/5] namei: O_BENEATH-style path resolution flags

On Wed, Mar 6, 2019 at 11:14 AM Aleksa Sarai <> wrote:
> This is a refresh of Al's AT_NO_JUMPS patchset[1] (which was a variation
> on David Drysdale's O_BENEATH patchset[2], which in turn was based on
> the Capsicum project[3]). Input from Linus and Andy in the AT_NO_JUMPS
> thread[4] determined most of the API changes made in this refresh.

So I still think this is likely a good idea...  BUT.

The absolutely huge BUT here is "are user space people actually
interested in using it, or do they already have other solutions to
this anyway?"

The intent is obviously to make it easy and cheap to to the simple
pathname lookup in a controlled manner, and then let user space fall
back to "let's check things much more carefully" for paths that look

But maybe the people who care already have their own solutions, and/or
need something more anyway (ie samba looking up all names in user
space first _anyway_ due to ICASE issues or whatever)?

So this is easy and straightforward to do in the kernel, and it
_feels_ like something that can be useful, and I'm not all that
concerned about the maintenance overhead either because of the trivial

But I'd still like to actually have some user space person say "yeah,
we'd actually use this" since quite often non-portable solutions don't
really end up being used simply because it's not worth the maintenance
headache in user space..


Powered by blists - more mailing lists