From: Giuseppe Scrivano <giuseppe@scrivano.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-unionfs@vger.kernel.org
Subject: Re: [RFC][PATCH] overlay: always follow metacopy into data-only layers
Date: Fri, 06 Nov 2026 10:40:21 +0100 [thread overview]
Message-ID: <87tslumh6i.fsf@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhmh7OpoGnNacFedBPm+jUQfDzv1QD4H+jTvb2kAPK=4Q@mail.gmail.com> (Amir Goldstein's message of "Fri, 6 Nov 2026 07:21:23 +0100")
Hi Amir,
Amir Goldstein <amir73il@gmail.com> writes:
> On Thu, Nov 5, 2026 at 3:37 PM Giuseppe Scrivano <giuseppe@scrivano.org> wrote:
>>
>> A metacopy file with an absolute redirect to a data-only layer is followed
>> without metacopy=on and redirect_dir=on only when it is in the last lower
>> layer. In any other lower layer, the next iteration of the loop in
>> ovl_lookup_layers() calls ovl_check_follow_redirect() with d->metacopy set
>> and fails with -EPERM.
>>
>> A mount with userxattr cannot have metacopy=on and redirect_dir=on, so a
>> user namespace mount that stacks several metadata-only layers over a
>> data-only layer can use the metacopy files of the last lower layer only:
>>
>> mount -t overlay none -o userxattr,lowerdir+=l3,lowerdir+=l2,\
>> lowerdir+=l1,datadir+=data,upperdir=u,workdir=w m
>> cat m/low # metacopy file in l1: works
>> cat m/mid # metacopy file in l2: Operation not permitted
>>
>> Skip the check inside the loop for a metacopy file of a lower layer with an
>> absolute redirect, on a mount that has data-only layers. The lookup of the
>> data stays lazy and happens only in the data-only layers. A metacopy file
>> or a redirect in the upper layer is still refused. With metacopy=on and
>> redirect_dir=on the loop already continues after such a file, so only
>> mounts that failed with -EPERM are affected.
>>
>> Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
>> ---
>> fs/overlayfs/namei.c | 13 +++++++++++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
>> index ca899fdfaafd..02c64a5652a0 100644
>> --- a/fs/overlayfs/namei.c
>> +++ b/fs/overlayfs/namei.c
>> @@ -1087,6 +1087,14 @@ struct ovl_lookup_ctx {
>> unsigned int ctr;
>> };
>>
>> +/* A metacopy file of a lower layer whose lowerdata is in a data-only layer */
>> +static bool ovl_is_datalayer_redirect(struct ovl_lookup_ctx *ctx,
>> + struct ovl_lookup_data *d)
>> +{
>> + return d->metacopy && ctx->ctr && OVL_FS(d->sb)->numdatalayer &&
>> + d->absolute_redirect;
>
> To further reduce risk, assuming that in the intended use case the data
> references always carry a digest, can we reinforce this to
> d->metacopy > OVL_METACOPY_MIN_SIZE?
I am not planning to use it only with fsverity. I'd like to use this
also on file systems where fs-verity is not supported, or if an user
decides to opt-out for any reason.
>
>> +}
>> +
>> static int ovl_lookup_layers(struct ovl_lookup_ctx *ctx, struct ovl_lookup_data *d)
>> {
>> struct dentry *dentry = ctx->dentry;
>> @@ -1154,7 +1162,8 @@ static int ovl_lookup_layers(struct ovl_lookup_ctx *ctx, struct ovl_lookup_data
>> for (i = 0; !d->stop && i < ovl_numlower(poe); i++) {
>> struct ovl_path lower = ovl_lowerstack(poe)[i];
>>
>> - if (!ovl_check_follow_redirect(d)) {
>> + if (!ovl_is_datalayer_redirect(ctx, d) &&
>> + !ovl_check_follow_redirect(d)) {
>> err = -EPERM;
>> return err;
>> }
>
> That's too promiscuous IMO to continue to loop as if nothing.
> You subject says "always follow metacopy into data-only layers"
> but this allows also following metacopy from l2 to l1 if there is a
> datalower and that makes no sense.
>
> What you would need to do is taint the lookup ctx in case we decided to
> follow against the follow_redirect/metacopy config in such a way
> that finding anything in the lower layers, even a whiteout or opaque
> object, will fail the lookup, because then we are not really allowing
> the intended follow into data-only layers.
>
> But I prefer to do it differently, see below
>
>> @@ -1238,7 +1247,7 @@ static int ovl_lookup_layers(struct ovl_lookup_ctx *ctx, struct ovl_lookup_data
>> * Defer lookup of lowerdata in data-only layers to first access.
>> * Don't require redirect=follow and metacopy=on in this case.
>> */
>> - if (d->metacopy && ctx->ctr && ofs->numdatalayer && d->absolute_redirect) {
>> + if (ovl_is_datalayer_redirect(ctx, d)) {
>> d->metacopy = 0;
>> ctx->ctr++;
>> } else if (!ovl_check_follow_redirect(d)) {
>> --
>> 2.56.0
>>
>>
>
> If the tooling can be changed we could introduce a special data-only
> follow marker and in this case we could just break out of the layers
> loop when it is encountered.
>
> Another option is to implement opt-in to redirect_dir=followdata
> which only allows following absolute redirects to the data-only layers
> which will stop the layers loop on first found redirect and requires
> a data-only layer of course.
>
> I prefer this option if it meets the user case's needs,
> because verifying that the redirect doesn't redirect to a lower layer
> just complicates the code for a corner case and runs unneeded
> cycles for no good reason.
from an initial test, this seems to work for me. If I don't encounter
other issues, I'll send another version later.
Thanks for your help!
Giuseppe
next prev parent reply other threads:[~2026-11-06 9:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 14:31 [RFC][PATCH] overlay: always follow metacopy into data-only layers Giuseppe Scrivano
2026-11-06 6:21 ` Amir Goldstein
2026-11-06 9:40 ` Giuseppe Scrivano [this message]
2026-11-06 12:25 ` Amir Goldstein
2026-11-06 13:32 ` Giuseppe Scrivano
2026-11-06 14:52 ` Amir Goldstein
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=87tslumh6i.fsf@redhat.com \
--to=giuseppe@scrivano.org \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
/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.