[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhRYtjJ9q4B_wLe89d5RBxWqpWzsKqAeAiDo5NhAYccVaQ@mail.gmail.com>
Date: Sun, 12 Nov 2023 15:29:14 -0500
From: Paul Moore <paul@...l-moore.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Miklos Szeredi <mszeredi@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
linux-security-module@...r.kernel.org, Karel Zak <kzak@...hat.com>,
Ian Kent <raven@...maw.net>,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Amir Goldstein <amir73il@...il.com>,
Matthew House <mattlloydhouse@...il.com>,
Florian Weimer <fweimer@...hat.com>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v4 4/6] add statmount(2) syscall
On Sun, Nov 12, 2023 at 8:06 AM Christian Brauner <brauner@...nel.org> wrote:
> On Fri, Nov 10, 2023 at 12:00:22PM -0500, Paul Moore wrote:
> > On Wed, Nov 8, 2023 at 3:10 PM Paul Moore <paul@...l-moore.com> wrote:
> > > On Wed, Nov 8, 2023 at 2:58 AM Christian Brauner <brauner@...nel.org> wrote:
> > > > > > +static int do_statmount(struct stmt_state *s)
> > > > > > +{
> > > > > > + struct statmnt *sm = &s->sm;
> > > > > > + struct mount *m = real_mount(s->mnt);
> > > > > > + size_t copysize = min_t(size_t, s->bufsize, sizeof(*sm));
> > > > > > + int err;
> > > > > > +
> > > > > > + err = security_sb_statfs(s->mnt->mnt_root);
> > > > > > + if (err)
> > > > > > + return err;
> > > > > > +
> > > > > > + if (!capable(CAP_SYS_ADMIN) &&
> > > > > > + !is_path_reachable(m, m->mnt.mnt_root, &s->root))
> > > > > > + return -EPERM;
> > > > >
> > > > > In order to be consistent with our typical access control ordering,
> > > > > please move the security_sb_statfs() call down to here, after the
> > > > > capability checks.
> > > >
> > > > I've moved the security_sb_statfs() calls accordingly.
> > >
> > > Okay, good. Did I miss a comment or a patch where that happened? I
> > > looked over the patchset and comments yesterday and didn't recall
> > > seeing anything about shuffling the access control checks.
> >
> > Gentle ping on this. I'm asking because I know there have been issues
> > lately with the lists and some mail providers and I want to make sure
> > I'm not missing anything, I double checked lore again and didn't see
> > anything there either, but I might be missing it.
>
> Sorry, I'm traveling so I just didn't see this. Please see:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.mount&id=dc14fa93943918bee898d75d7ae72fc3623ce9ce
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.mount&id=de17643cbf9b0282990bb9cf0e0bf01710c9ec03
>
> I've folded the fixup into these patches. I probably just accidently
> dropped the diff from my reply.
Okay, no worries, like I said I was mostly worried about mail/list
problems eating the response.
Thanks for fixing the access control ordering, but FWIW I was a little
surprised not to see a note, e.g. "[CB: changed access control
ordering]" or similar, in the metadata.
--
paul-moore.com
Powered by blists - more mailing lists