From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
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,
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@vger.kernel.orgCh
Subject: Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 12:20:17 +0000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: 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>,
containers@lists.linux-foundation.org,
linux-alpha@vger.kernel.org, linux-api@vger.kernel.org,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-kernel@vger.kernel.org, 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 v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 22:20:17 +1000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
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,
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@vger.kernel.orgCh
Subject: Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 22:20:17 +1000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
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,
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@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-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org
Subject: Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 22:20:17 +1000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
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,
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@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-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
containers@lists.linux-foundation.org
Subject: Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 22:20:17 +1000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
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,
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@vger.kernel.org, Ch
Subject: Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions
Date: Fri, 12 Jul 2019 22:20:17 +1000 [thread overview]
Message-ID: <20190712122017.xkowq2cjreylpotm@yavin> (raw)
In-Reply-To: <20190712041454.GG17978@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]
On 2019-07-12, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_link_count = old ? old->total_link_count : 0;
> > + p->total_link_count = 0;
> > + p->acc_mode = 0;
> > + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> > + if (old) {
> > + p->total_link_count = old->total_link_count;
> > + p->acc_mode = old->acc_mode;
> > + p->opath_mask = old->opath_mask;
> > + }
>
> Huh? Could somebody explain why traversals of NFS4 referrals should inherit
> ->acc_mode and ->opath_mask?
I'll be honest -- I don't understand what set_nameidata() did so I just
did what I thought would be an obvious change (to just copy the
contents). I thought it was related to some aspect of the symlink stack
handling.
In that case, should they both be set to 0 on set_nameidata()? This will
mean that fd re-opening (or magic-link opening) through a
set_nameidata() would always fail.
> > static __always_inline
> > -const char *get_link(struct nameidata *nd)
> > +const char *get_link(struct nameidata *nd, bool trailing)
> > {
> > struct saved *last = nd->stack + nd->depth - 1;
> > struct dentry *dentry = last->link.dentry;
> > @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
> > } else {
> > res = get(dentry, inode, &last->done);
> > }
> > + /* If we just jumped it was because of a magic-link. */
> > + if (unlikely(nd->flags & LOOKUP_JUMPED)) {
> [...]
> In any case, this "bool trailing" is completely wrong; whether that
> check belongs in trailing_symlink() or (some of) its callers, putting
> it into get_link() is a mistake, forced by kludgy check for procfs-style
> symlinks.
The error path for LOOKUP_JUMPED comes from the old O_BENEATH patchset,
but all of the "bool trailing" logic is definitely my gaff (I was
quietly hoping you'd have a much better solution than the whole
get_link() thing -- it definitely felt very kludgey to write).
I will work on the suggestion in your follow-up email. Thanks!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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-07-12 12:20 UTC|newest]
Thread overview: 243+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-06 14:57 [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-12 4:14 ` Al Viro
2019-07-12 4:14 ` Al Viro
2019-07-12 4:14 ` Al Viro
2019-07-12 4:14 ` Al Viro
2019-07-12 4:14 ` Al Viro
2019-07-12 6:36 ` Al Viro
2019-07-12 6:36 ` Al Viro
2019-07-12 6:36 ` Al Viro
2019-07-12 6:36 ` Al Viro
2019-07-12 6:36 ` Al Viro
2019-07-12 12:20 ` Aleksa Sarai [this message]
2019-07-12 12:20 ` Aleksa Sarai
2019-07-12 12:20 ` Aleksa Sarai
2019-07-12 12:20 ` Aleksa Sarai
2019-07-12 12:20 ` Aleksa Sarai
2019-07-12 12:20 ` Aleksa Sarai
2019-07-12 13:10 ` Al Viro
2019-07-12 13:10 ` Al Viro
2019-07-12 13:10 ` Al Viro
2019-07-12 13:10 ` Al Viro
2019-07-12 13:10 ` Al Viro
2019-07-14 7:11 ` Aleksa Sarai
2019-07-14 7:11 ` Aleksa Sarai
2019-07-14 7:11 ` Aleksa Sarai
2019-07-14 7:11 ` Aleksa Sarai
2019-07-14 7:11 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 02/10] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 03/10] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-12 4:20 ` Al Viro
2019-07-12 4:20 ` Al Viro
2019-07-12 4:20 ` Al Viro
2019-07-12 4:20 ` Al Viro
2019-07-12 4:20 ` Al Viro
2019-07-12 12:07 ` Aleksa Sarai
2019-07-12 12:07 ` Aleksa Sarai
2019-07-12 12:07 ` Aleksa Sarai
2019-07-12 12:07 ` Aleksa Sarai
2019-07-12 12:07 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-12 12:12 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-12 4:33 ` Al Viro
2019-07-12 4:33 ` Al Viro
2019-07-12 4:33 ` Al Viro
2019-07-12 4:33 ` Al Viro
2019-07-12 4:33 ` Al Viro
2019-07-12 4:33 ` Al Viro
2019-07-12 10:57 ` Aleksa Sarai
2019-07-12 10:57 ` Aleksa Sarai
2019-07-12 10:57 ` Aleksa Sarai
2019-07-12 10:57 ` Aleksa Sarai
2019-07-12 10:57 ` Aleksa Sarai
2019-07-12 12:39 ` Al Viro
2019-07-12 12:39 ` Al Viro
2019-07-12 12:39 ` Al Viro
2019-07-12 12:39 ` Al Viro
2019-07-12 12:39 ` Al Viro
2019-07-12 12:39 ` Al Viro
2019-07-12 12:55 ` Al Viro
2019-07-12 12:55 ` Al Viro
2019-07-12 12:55 ` Al Viro
2019-07-12 12:55 ` Al Viro
2019-07-12 12:55 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 13:25 ` Al Viro
2019-07-12 15:00 ` Al Viro
2019-07-12 15:00 ` Al Viro
2019-07-12 15:00 ` Al Viro
2019-07-12 15:00 ` Al Viro
2019-07-12 15:00 ` Al Viro
2019-07-13 2:41 ` Al Viro
2019-07-13 2:41 ` Al Viro
2019-07-13 2:41 ` Al Viro
2019-07-13 2:41 ` Al Viro
2019-07-13 2:41 ` Al Viro
2019-07-14 3:58 ` Al Viro
2019-07-14 3:58 ` Al Viro
2019-07-14 3:58 ` Al Viro
2019-07-14 3:58 ` Al Viro
2019-07-14 3:58 ` Al Viro
2019-07-16 8:03 ` Aleksa Sarai
2019-07-16 8:03 ` Aleksa Sarai
2019-07-16 8:03 ` Aleksa Sarai
2019-07-16 8:03 ` Aleksa Sarai
2019-07-16 8:03 ` Aleksa Sarai
2019-07-14 7:00 ` Aleksa Sarai
2019-07-14 7:00 ` Aleksa Sarai
2019-07-14 7:00 ` Aleksa Sarai
2019-07-14 7:00 ` Aleksa Sarai
2019-07-14 7:00 ` Aleksa Sarai
2019-07-14 14:36 ` Al Viro
2019-07-14 14:36 ` Al Viro
2019-07-14 14:36 ` Al Viro
2019-07-14 14:36 ` Al Viro
2019-07-14 14:36 ` Al Viro
2019-07-18 3:17 ` Aleksa Sarai
2019-07-18 3:17 ` Aleksa Sarai
2019-07-18 3:17 ` Aleksa Sarai
2019-07-18 3:17 ` Aleksa Sarai
2019-07-18 3:17 ` Aleksa Sarai
2019-07-14 10:31 ` Aleksa Sarai
2019-07-14 10:31 ` Aleksa Sarai
2019-07-14 10:31 ` Aleksa Sarai
2019-07-14 10:31 ` Aleksa Sarai
2019-07-14 10:31 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 06/10] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 07/10] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 08/10] open: openat2(2) syscall Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-18 14:48 ` Rasmus Villemoes
2019-07-18 14:48 ` Rasmus Villemoes
2019-07-18 14:48 ` Rasmus Villemoes
2019-07-18 14:48 ` Rasmus Villemoes
2019-07-18 14:48 ` Rasmus Villemoes
2019-07-18 15:21 ` Aleksa Sarai
2019-07-18 15:21 ` Aleksa Sarai
2019-07-18 15:21 ` Aleksa Sarai
2019-07-18 15:21 ` Aleksa Sarai
2019-07-18 15:21 ` Aleksa Sarai
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 15:10 ` Arnd Bergmann
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 16:12 ` Aleksa Sarai
2019-07-18 21:29 ` Arnd Bergmann
2019-07-18 21:29 ` Arnd Bergmann
2019-07-18 21:29 ` Arnd Bergmann
2019-07-18 21:29 ` Arnd Bergmann
2019-07-18 21:29 ` Arnd Bergmann
2019-07-18 21:29 ` Arnd Bergmann
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 2:12 ` Dmitry V. Levin
2019-07-19 10:29 ` Christian Brauner
2019-07-19 10:29 ` Christian Brauner
2019-07-19 10:29 ` Christian Brauner
2019-07-19 10:29 ` Christian Brauner
2019-07-19 10:29 ` Christian Brauner
2019-07-19 10:29 ` Christian Brauner
2019-07-19 1:59 ` Dmitry V. Levin
2019-07-19 1:59 ` Dmitry V. Levin
2019-07-19 1:59 ` Dmitry V. Levin
2019-07-19 1:59 ` Dmitry V. Levin
2019-07-19 1:59 ` Dmitry V. Levin
2019-07-19 2:19 ` Aleksa Sarai
2019-07-19 2:19 ` Aleksa Sarai
2019-07-19 2:19 ` Aleksa Sarai
2019-07-19 2:19 ` Aleksa Sarai
2019-07-19 2:19 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 09/10] kselftest: save-and-restore errno to allow for %m formatting Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 10/10] selftests: add openat2(2) selftests Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 1:15 ` Michael Ellerman
2019-07-08 5:47 ` Aleksa Sarai
2019-07-08 5:47 ` Aleksa Sarai
2019-07-08 5:47 ` Aleksa Sarai
2019-07-08 5:47 ` Aleksa Sarai
2019-07-08 5:47 ` Aleksa Sarai
2019-07-12 15:11 ` [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Al Viro
2019-07-12 15:11 ` Al Viro
2019-07-12 15:11 ` Al Viro
2019-07-12 15:11 ` Al Viro
2019-07-12 15:11 ` Al Viro
2019-07-12 15:32 ` Aleksa Sarai
2019-07-12 15:32 ` Aleksa Sarai
2019-07-12 15:32 ` Aleksa Sarai
2019-07-12 15:32 ` Aleksa Sarai
2019-07-12 15:32 ` 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=20190712122017.xkowq2cjreylpotm@yavin \
--to=cyphar@cyphar.com \
--cc=arnd@arndb.de \
--cc=asarai@suse.de \
--cc=ast@kernel.org \
--cc=bfields@fieldses.org \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=drysdale@google.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.orgCh \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=sparclinux@vger.kernel.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.