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

[Alexander Larsson <alexl@redhat.com>]

On Thu, 2025-03-27 at 20:23 +0100, Miklos Szeredi wrote:
> On Thu, 27 Mar 2025 at 18:14, Amir Goldstein <amir73il@gmail.com>
> wrote:
> > origin xattr only checks from upper to uppermost lower layer IIRC,
> > do definitely not all the way to lowerdata inode.
> 
> Makes sense.
> 
> > > so as long as the user is unable to change the origin integrity
> > > should
> > > be guaranteed.  IOW, what we need is just to always check origin
> > > on
> > > metacopy regardless of the index option.
> > > 
> > > But I'm not even sure this is used at all, since the verity code
> > > was
> > > added for the composefs use case, which does not use this path
> > > AFAICS.
> > > Alex, can you clarify?
> > 
> > I am not sure how composefs lowerdata layer is being deployed,
> > but but I am pretty sure that the composefs erofs layers are
> > designed to be migratable to any fs where the lowerdata repo
> > exists, so I think hard coding the lowerdata inode is undesired.
> 
> Yeah, I understand the basic composefs architecture, and storing the
> digest in the metadata inode makes perfect sense.
> 
> What I'm not sure is what is being used outside of that.
> 
> Anyway, I don't see any issue with the current architecture, just
> trying to understand what this is useful for and possible
> simplifications based on that.
> 
> For example the copy-up code is apparently unused, and could be
> removed.  OTOH it could be useful for the idmapping case from
> Guiseppe.

I think there are two basic composefs usecases, first a completely
read-only one with a data-only, an erofs lower and nothing more. The
traditional example here is a read-only rootfs. In this case, clearly
digest copy-up is not needed.

The second usecase is when you use composefs for a container image,
similar to use case 1, but on top of that you have the writable upper
layer that is for the running container itself. In this case, you want
to validate all accesses to the lower layer, but allow the container to
make changes. Obviously, once you create a new file, or modify a lower
one there will not be any validation of that file. 

However, if you for example change just file ownership, then you may
trigger a meta-copy-up, and at this point it makes sense to also copy
up the digest to the metacopy file, because otherwise accesses to it
would read the datadir file without validating its digest. 

Unfortunately this (as you say) weakens the security in the case the
raw upperdir is not trusted, as it would allow the digest xattr to be
changed. But I think this is acceptable, because the alternative
without meta-copy-up is a full copy up, but then you can change the
file data in the upper instead, which is even worse.

As for origin checks, they are really never interesting to any
composefs-style usecase, because those are fundamentally about
transporting images between different systems (with different
filesystems, inodes, etc).


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=
 Alexander Larsson                                            Red Hat,
Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's a superhumanly strong coffee-fuelled firefighter who hides his 
scarred face behind a mask. She's a sarcastic mute opera singer who 
inherited a spooky stately manor from her late maiden aunt. They fight 
crime!