Re: [PATCH 3/5] ovl: make redirect/metacopy rejection consistent

[Giuseppe Scrivano <gscrivan@redhat.com>]

Alexander Larsson <alexl@redhat.com> writes:

> On Tue, 2025-03-25 at 11:57 +0100, Miklos Szeredi wrote:
>> On Tue, 11 Feb 2025 at 13:01, Amir Goldstein <amir73il@gmail.com>
>> wrote:
>> > Looking closer at ovl_maybe_validate_verity(), it's actually
>> > worse - if you create an upper without metacopy above
>> > a lower with metacopy, ovl_validate_verity() will only check
>> > the metacopy xattr on metapath, which is the uppermost
>> > and find no md5digest, so create an upper above a metacopy
>> > lower is a way to avert verity check.
>> > 
>> > So I think lookup code needs to disallow finding metacopy
>> > in middle layer and need to enforce that also when upper is found
>> > via index.
>> 
>> So I think the next patch does this: only allow following a metacopy
>> redirect from lower to data.
>> 
>> It's confusing to call this metacopy, as no copy is performed.  We
>> could call it data-redirect.  Mixing data-redirect with real meta-
>> copy
>> is of dubious value, and we might be better to disable it even in the
>> privileged scenario.
>> 
>> Giuseppe, Alexander, AFAICS the composefs use case employs
>> data-redirect only and not metacopy, right?
>
> The most common usecase is to get a read-only image, say for
> /usr. However, sometimes (for example with containers) we have a
> writable upper layer too. I'm not sure how important metacopy is for
> that though, it is more commonly used to avoid duplicating things
> between e.g. the container image layers. Giuseppe?

for the composefs use case we don't need metacopy, but if it is possible
it would be nice to have metacopy since idmapped mounts do not work yet
in a user namespace.  So each time we run a container in a different
mapping we need a fully copy of the image which would be faster with
metacopy.

Regards,
Giuseppe