From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Eric Biederman <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Tycho Andersen <tycho@tycho.ws>,
David Drysdale <drysdale@google.com>,
Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
Aleksa Sarai <asarai@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-f
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 20:17:33 +0000 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Eric Biederman <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Tycho Andersen <tycho@tycho.ws>,
David Drysdale <drysdale@google.com>,
Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
Aleksa Sarai <asarai@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org,
linux-alpha@vger.kernel.org,
Linux API <linux-api@vger.kernel.org>,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 13:17:33 -0700 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Eric Biederman <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Tycho Andersen <tycho@tycho.ws>,
David Drysdale <drysdale@google.com>,
Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
Aleksa Sarai <asarai@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org,
linux-alpha@vger.kernel.org,
Linux API <linux-api@vger.kernel.org>,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 13:17:33 -0700 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Eric Biederman <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Tycho Andersen <tycho@tycho.ws>,
David Drysdale <drysdale@google.com>,
Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
Aleksa Sarai <asarai@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-f
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 13:17:33 -0700 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
sparclinux@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Tycho Andersen <tycho@tycho.ws>, Aleksa Sarai <asarai@suse.de>,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-xtensa@linux-xtensa.org, Kees Cook <keescook@chromium.org>,
Arnd Bergmann <arnd@arndb.de>, Jann Horn <jannh@google.com>,
linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org,
Al Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
David Drysdale <drysdale@google.com>,
Christian Brauner <christian@brauner.io>,
"J. Bruce Fields" <bfields@fieldses.org>,
linux-parisc@vger.kernel.org,
Linux API <linux-api@vger.kernel.org>,
Chanho Min <chanho.min@lge.com>, Jeff Layton <jlayton@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
linux-alpha@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 13:17:33 -0700 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
sparclinux@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Tycho Andersen <tycho@tycho.ws>, Aleksa Sarai <asarai@suse.de>,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-xtensa@linux-xtensa.org, Kees Cook <keescook@chromium.org>,
Arnd Bergmann <arnd@arndb.de>, Jann Horn <jannh@google.com>,
linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org,
Al Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
David Drysdale <drysdale@google.com>,
Christian Brauner <christian@brauner.io>,
"J. Bruce Fields" <bfields@fieldses.org>,
linux-parisc@vger.kernel.org,
Linux API <linux-api@vger.kernel.org>,
Chanho Min <chanho.min@lge.com>, Jeff Layton <jlayton@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
linux-alpha@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Sat, 24 Aug 2019 13:17:33 -0700 [thread overview]
Message-ID: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com> (raw)
In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com>
On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2). However, there are a few reasons why this is
> not the best course of action:
>
> * The new LOOKUP_* flags are intended to be security features, and
> openat(2) will silently ignore all unknown flags. This means that
> users would need to avoid foot-gunning themselves constantly when
> using this interface if it were part of openat(2). This can be fixed
> by having userspace libraries handle this for users[1], but should be
> avoided if possible.
>
> * Resolution scoping feels like a different operation to the existing
> O_* flags. And since openat(2) has limited flag space, it seems to be
> quite wasteful to clutter it with 5 flags that are all
> resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> its entire purpose is to error out if you encounter a trailing
> symlink -- not to scope resolution.
>
> * Other systems would be able to reimplement this syscall allowing for
> cross-OS standardisation rather than being hidden amongst O_* flags
> which may result in it not being used by all the parties that might
> want to use it (file servers, web servers, container runtimes, etc).
>
> * It gives us the opportunity to iterate on the O_PATH interface. In
> particular, the new @how->upgrade_mask field for fd re-opening is
> only possible because we have a clean slate without needing to re-use
> the ACC_MODE flag design nor the existing openat(2) @mode semantics.
>
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.
>
> In order to allow for userspace to lock down their usage of file
> descriptor re-opening, openat2(2) has the ability for users to disallow
> certain re-opening modes through @how->upgrade_mask. At the moment,
> there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> for future extensions (all of the reserved bits must be zeroed).
Why pad the structure when new functionality (perhaps accommodated via
a larger structure) could be signaled by passing a new flag? Adding
reserved fields to a structure with a size embedded in the ABI makes a
lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
can grow, so the reservation seems needless to me.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-24 20:17 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 3:33 [PATCH RESEND v11 0/8] openat2(2) Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` [PATCH RESEND v11 1/8] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:33 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 2/8] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 3/8] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 4/8] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 5/8] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 6/8] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` [PATCH RESEND v11 7/8] open: openat2(2) syscall Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-24 20:17 ` Daniel Colascione [this message]
2019-08-24 20:17 ` Daniel Colascione
2019-08-24 20:17 ` Daniel Colascione
2019-08-24 20:17 ` Daniel Colascione
2019-08-24 20:17 ` Daniel Colascione
2019-08-24 20:17 ` Daniel Colascione
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 12:15 ` Aleksa Sarai
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:05 ` Rasmus Villemoes
2019-08-29 13:19 ` Aleksa Sarai
2019-08-29 13:19 ` Aleksa Sarai
2019-08-29 13:19 ` Aleksa Sarai
2019-08-29 13:19 ` Aleksa Sarai
2019-08-29 13:19 ` Aleksa Sarai
2019-08-29 13:19 ` Aleksa Sarai
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-26 19:50 ` sbaugh
2019-08-28 15:55 ` Jeff Layton
2019-08-28 15:55 ` Jeff Layton
2019-08-28 15:55 ` Jeff Layton
2019-08-28 15:55 ` Jeff Layton
2019-08-28 20:17 ` Spencer Baugh
2019-08-28 20:17 ` Spencer Baugh
2019-08-28 20:17 ` Spencer Baugh
2019-08-20 3:34 ` [PATCH RESEND v11 8/8] selftests: add openat2(2) selftests Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
2019-08-20 3:34 ` Aleksa Sarai
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='CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com' \
--to=dancol@google.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=asarai@suse.de \
--cc=ast@kernel.org \
--cc=bfields@fieldses.org \
--cc=chanho.min@lge.com \
--cc=christian@brauner.io \
--cc=containers@lists.linux-f \
--cc=cyphar@cyphar.com \
--cc=dhowells@redhat.com \
--cc=drysdale@google.com \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=jlayton@kernel.org \
--cc=keescook@chromium.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=torvalds@linux-foundation.org \
--cc=tycho@tycho.ws \
--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.