[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegsct9a9D8p==mQcAfN_pJWWbXSj4oM9LHgTQEk+KPPaAw@mail.gmail.com>
Date: Fri, 15 Sep 2023 11:10:08 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Paul Moore <paul@...l-moore.com>
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>
Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall
On Thu, 14 Sept 2023 at 22:40, Paul Moore <paul@...l-moore.com> wrote:
>
> On Wed, Sep 13, 2023 at 11:23 AM Miklos Szeredi <mszeredi@...hat.com> wrote:
> ...
>
> > +static int do_statmnt(struct stmt_state *s)
> > +{
> > + struct statmnt *sm = &s->sm;
> > + struct mount *m = real_mount(s->mnt);
> > +
> > + if (!capable(CAP_SYS_ADMIN) &&
> > + !is_path_reachable(m, m->mnt.mnt_root, &s->root))
> > + return -EPERM;
>
> I realize statmnt() is different from fstatfs(), but from an access
> control perspective they look a lot alike to me which is why I think
> we should probably have a security_sb_statfs() call here. Same thing
> for the listmnt() syscall in patch 3/3.
Okay, makes sense.
Thanks,
Miklos
Powered by blists - more mailing lists