All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Amir Goldstein <amir73il@gmail.com>
Cc: cui.tao@linux.dev, linux-unionfs@vger.kernel.org,
	miklos@szeredi.hu, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Tao Cui <cuitao@kylinos.cn>
Subject: Re: [PATCH] ovl: reject verity= together with userxattr
Date: Thu, 3 Sep 2026 17:11:37 +0800	[thread overview]
Message-ID: <de02c1f0-c675-4050-a2ee-2584eda63499@linux.dev> (raw)
In-Reply-To: <CAOQ4uxhZOBv93_y4K0mc4PofprdPfSN8c45KW226LR-JO_BEkw@mail.gmail.com>

Hi Amir,

在 2026/9/3 16:09, Amir Goldstein 写道:
> On Thu, Sep 3, 2026 at 8:45 AM Tao Cui <cui.tao@linux.dev> wrote:
>>
>> From: Tao Cui <cuitao@kylinos.cn>
>>
>> userxattr forces metacopy off, and copy-up only computes and stores
>> the verity digest for metacopy inodes.  With "userxattr,verity=on"
>> (or verity=require) the mount succeeds, verity is advertised in
>> mountinfo, but no digest is ever generated and no lowerdata is ever
>> verified - the option silently does nothing:
>>
>>   $ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
>>   (mount succeeds; after copy-up the upper inode carries only the
>>    origin xattr, no metacopy xattr, no digest)
> 
> If metacopy is disabled, then the data of the upper file is in the upper file
> there is not supposed to be a verity signature for the upper file data
> verity signature is to attest the data of the lower file, so this report
> is strange.
> 
> Moreover, even though metacopy=off does not create new meta copies,
> it still respects existing metacopy xattr, which may very well also contain a
> verity digest, so the statement "silently does nothing" is inaccurate.
> 
> I admit that user xattrs for verity digest is an odd combination, but it does
> what it is supposed to do.
> 
> If you want to report a bug please explain how the security model gets
> broken.
> 

Thanks for the explanation.  I hadn't considered that pre-existing
metacopy xattrs are still respected regardless of the mount option,
and that with metacopy off the copy-up data lives in the upper file
where there is nothing to attest.  The patch gets this wrong, please
drop it.

The fs-verity section in overlayfs.rst does spell this out; I read
it too narrowly.

Thanks,
Tao

> Thanks,
> Amir.


      reply	other threads:[~2026-09-03  9:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03  6:45 [PATCH] ovl: reject verity= together with userxattr Tao Cui
2026-09-03  8:09 ` Amir Goldstein
2026-09-03  9:11   ` Tao Cui [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=de02c1f0-c675-4050-a2ee-2584eda63499@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=amir73il@gmail.com \
    --cc=cuitao@kylinos.cn \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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.