From: Andy Lutomirski <luto@kernel.org>
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>,
Andy Lutomirski <luto@kernel.org>,
Christian Brauner <christian@brauner.io>,
Eric Biederman <ebiederm@xmission.com>,
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>,
Linux Containers <containers@lists.linux-foundation.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH RFC v8 01/10] namei: obey trailing magic-link DAC permissions
Date: Wed, 22 May 2019 10:01:17 -0700 [thread overview]
Message-ID: <CALCETrVCwe49q5mu=f6jTYNSgosQSjjY5chukMPo6eZtQGqo5g@mail.gmail.com> (raw)
In-Reply-To: <20190520133305.11925-2-cyphar@cyphar.com>
On Mon, May 20, 2019 at 6:34 AM Aleksa Sarai <cyphar@cyphar.com> wrote:
> One final exception is given, which is that non-O_PATH file descriptors
> are given re-open rights equivalent to the permissions available at
> open-time. This allows for O_RDONLY file descriptors to be re-opened
> O_RDWR as long as the user had MAY_WRITE access at the time of opening
> the O_RDONLY descriptor. This is necessary to avoid breaking userspace
> (some of the kernel's own selftests depended on this "feature").
Can you clarify this exception a bit? I'd like to make sure it's not
such a huge exception that it invalidates the whole point of the
patch. If you open a file for execute, by actually exec()ing it or by
using something like the proposed O_MAYEXEC, and you have
inode_permission to write, do you still end up with FMODE_PATH_WRITE?
The code looks like it does, and this seems like it might be a
mistake. Is there any way for user code to read out these new file
mode bits?
What are actual examples of uses for this exception? Breaking
selftests is not, in and of itself, a huge problem.
next prev parent reply other threads:[~2019-05-22 17:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 13:32 [PATCH RFC v8 00/10] namei: resolveat(2) path resolution restrictions Aleksa Sarai
2019-05-20 13:32 ` [PATCH RFC v8 01/10] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-05-22 17:01 ` Andy Lutomirski [this message]
2019-05-23 2:00 ` Aleksa Sarai
2019-05-24 3:11 ` Aleksa Sarai
2019-05-29 15:10 ` Andy Lutomirski
2019-05-20 13:32 ` [PATCH RFC v8 02/10] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-05-20 13:32 ` [PATCH RFC v8 03/10] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-05-20 13:32 ` [PATCH RFC v8 04/10] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 05/10] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 06/10] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 07/10] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 08/10] namei: resolveat(2) syscall Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 09/10] kselftest: save-and-restore errno to allow for %m formatting Aleksa Sarai
2019-05-20 13:33 ` [PATCH RFC v8 10/10] selftests: add resolveat(2) selftests 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='CALCETrVCwe49q5mu=f6jTYNSgosQSjjY5chukMPo6eZtQGqo5g@mail.gmail.com' \
--to=luto@kernel.org \
--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-foundation.org \
--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=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.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 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).