Linux fsverity development list
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Andrey Albershteyn <aalbersh@kernel.org>
Cc: fsverity@lists.linux.dev
Subject: Re: [PATCH] fsverity: Update misleading comment in fsverity_ioctl_read_metadata()
Date: Thu, 22 Oct 2026 19:59:30 +0000	[thread overview]
Message-ID: <20261022195930.GA1383716@google.com> (raw)
In-Reply-To: <atnUhNPNf651wjw7@aalbersh-thinkpadx1carbongen13.rmtcz.csb>

On Thu, Oct 22, 2026 at 11:17:26AM +0200, Andrey Albershteyn wrote:
> On 2026-10-21 22:40:30, Eric Biggers wrote:
> > The comment in fsverity_ioctl_read_metadata(), which justifies not
> > checking for FMODE_READ, doesn't consider that the nonstandard access
> > mode 3 (ioctl-only) exists.
> > 
> > It's reasonable to continue to allow this ioctl in that case, since this
> > *is* an ioctl, and opening a file with mode 3 checks for read (and
> > write) access.  However, adjust the comment to not be misleading.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> 
> Looks good to me
> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>

Thanks.  I'm actually reconsidering this patch, though:

* This ioctl returns hashes of file contents blocks, which reveal
  information that normally a read would be needed for.

* "opening a file with mode 3 checks for read (and write) access"
  is true for the DAC permissions, but it's not true for some LSMs such
  as Landlock where it bypasses their read permission check.

So requiring FMODE_READ for this might be the way to go.

- Eric

      reply	other threads:[~2026-10-22 19:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 22:40 [PATCH] fsverity: Update misleading comment in fsverity_ioctl_read_metadata() Eric Biggers
2026-10-22  9:17 ` Andrey Albershteyn
2026-10-22 19:59   ` Eric Biggers [this message]

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=20261022195930.GA1383716@google.com \
    --to=ebiggers@kernel.org \
    --cc=aalbersh@kernel.org \
    --cc=fsverity@lists.linux.dev \
    /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