From: "Günther Noack" <gnoack@google.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-security-module@vger.kernel.org,
"Mickaël Salaün" <mic@digikod.net>, "Jeff Xu" <jeffxu@google.com>,
"Jorge Lucangeli Obes" <jorgelo@chromium.org>,
"Allen Webb" <allenwebb@google.com>,
"Dmitry Torokhov" <dtor@google.com>,
"Paul Moore" <paul@paul-moore.com>,
"Konstantin Meskhidze" <konstantin.meskhidze@huawei.com>,
"Matt Bobrowski" <repnop@google.com>,
linux-fsdevel@vger.kernel.org,
"Christian Brauner" <brauner@kernel.org>
Subject: Re: [PATCH v11 1/9] fs: Add and use vfs_get_ioctl_handler()
Date: Mon, 25 Mar 2024 14:25:16 +0100 [thread overview]
Message-ID: <ZgF7PFWDIxoFdgIb@google.com> (raw)
In-Reply-To: <32b1164e-9d5f-40c0-9a4e-001b2c9b822f@app.fastmail.com>
On Fri, Mar 22, 2024 at 04:31:58PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 22, 2024, at 16:09, Günther Noack wrote:
> > From: Mickaël Salaün <mic@digikod.net>
> >
> > Add a new vfs_get_ioctl_handler() helper to identify if an IOCTL command
> > is handled by the first IOCTL layer. Each IOCTL command is now handled
> > by a dedicated function, and all of them use the same signature.
>
> Sorry I didn't already reply the previous time you sent this.
> I don't really like the idea of going through another indirect
> pointer for each of the ioctls here, both because of the
> complexity at the source level, and the potential cost on
> architectures that need heavy barriers around indirect
> function calls.
>
> > -static int ioctl_fibmap(struct file *filp, int __user *p)
> > +static int ioctl_fibmap(struct file *filp, unsigned int fd, unsigned
> > long arg)
> > {
> > + int __user *p = (void __user *)arg;
>
> The new version doesn't seem like an improvement when you
> need the extra type casts here.
>
> As a completely different approach, would it perhaps be
> sufficient to define security_file_ioctl_compat() in a
> way that it may return a special error code signifying
> "don't call into fops->{unlocked,compat}_ioctl"?
>
> This way landlock could trivially allow ioctls on e.g.
> normal file systems, sockets and block devices but prevent
> them on character devices it does not trust.
Thank you for the review, Arnd! I gave your suggestion a shot and it seems
cleaner - I'll send an updated patch shortly.
—Günther
next prev parent reply other threads:[~2024-03-25 13:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 15:09 [PATCH v11 0/9] Landlock: IOCTL support Günther Noack
2024-03-22 15:09 ` [PATCH v11 1/9] fs: Add and use vfs_get_ioctl_handler() Günther Noack
2024-03-22 15:31 ` Arnd Bergmann
2024-03-25 13:25 ` Günther Noack [this message]
2024-03-22 15:09 ` [PATCH v11 2/9] landlock: Add IOCTL access right for character and block devices Günther Noack
2024-03-22 15:09 ` [PATCH v11 3/9] selftests/landlock: Test IOCTL support Günther Noack
2024-03-22 15:09 ` [PATCH v11 4/9] selftests/landlock: Test IOCTL with memfds Günther Noack
2024-03-22 15:09 ` [PATCH v11 5/9] selftests/landlock: Test ioctl(2) and ftruncate(2) with open(O_PATH) Günther Noack
2024-03-22 15:09 ` [PATCH v11 6/9] selftests/landlock: Test IOCTLs on named pipes Günther Noack
2024-03-22 15:10 ` [PATCH v11 7/9] selftests/landlock: Check IOCTL restrictions for named UNIX domain sockets Günther Noack
2024-03-22 15:10 ` [PATCH v11 8/9] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL_DEV Günther Noack
2024-03-22 15:10 ` [PATCH v11 9/9] landlock: Document IOCTL support Günther Noack
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=ZgF7PFWDIxoFdgIb@google.com \
--to=gnoack@google.com \
--cc=allenwebb@google.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=dtor@google.com \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=repnop@google.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).