fs/overlayfs/params.c | 5 +++++ 1 file changed, 5 insertions(+)
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)
Follow the existing pattern for redirect_dir/metacopy and reject the
explicit combination at parse time:
$ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
mount: /mnt: wrong fs type, bad option, bad superblock...
overlayfs: conflicting options: userxattr,verity=on
This does not affect per-file fs-verity on the lower layers used
together with userxattr (e.g. fstests overlay/089): it only concerns
the verity= mount option, whose copy-up digest semantics cannot be
honored when userxattr forces metacopy off.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
fs/overlayfs/params.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index c93fcaa45d4a..29dfc16fecc9 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -997,6 +997,11 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx,
pr_err("conflicting options: userxattr,metacopy=on\n");
return -EINVAL;
}
+ if (config->verity_mode) {
+ pr_err("conflicting options: userxattr,verity=%s\n",
+ ovl_verity_mode(config));
+ return -EINVAL;
+ }
/*
* Silently disable default setting of redirect and metacopy.
* This shall be the default in the future as well: these
--
2.43.0
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, Amir.
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.
© 2016 - 2026 Red Hat, Inc.