Re: [PATCH] ovl: reject verity= together with userxattr

[Tao Cui]

Hi Amir,

在 2026/9/3 16:09, Amir Goldstein 写道:
> On Thu, Sep 3, 2026 at 8:45 AM Tao Cui <cui.tao@xxxxxxxxx> wrote:
>>
>> From: Tao Cui <cuitao@xxxxxxxxxx>
>>
>> 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.