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

[Miklos Szeredi <miklos@szeredi.hu>]

On Tue, 25 Mar 2025 at 14:34, Giuseppe Scrivano <gscrivan@redhat.com> wrote:
>
> 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.

Okay, so there is a usecase for compose + metacopy.

Problem seems to be that this negatively affects the security of the
setup, because the digest is now stored on the unverified upper layer.
Am I misunderstanding this?

Thanks,
Miklos