On Tue, 2025-03-25 at 08:51 -0400, Colin Walters wrote:
> On Tue, Mar 25, 2025 at 7:18 AM Alexander Larsson <alexl@xxxxxxxxxx>
> wrote:
>
> > > 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.
>
> That sounds right to me, yes. Especially when fsverity is required,
> hopefully we can keep the code paths involved as simple as possible.
>
> > The most common usecase is to get a read-only image
>
> Yes, especially for signed images that require fsverity - often the
> deployments of those will not want a writable upper because we want
> to be able to ultimately pair it with policies to enforce userspace
> execution from verity/composefs like IPE etc.
>
> > 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?
>
> Wait isn't that statement backwards? metacopy is just for optimizing
> the metadata-only copyup-from-lower case when having a writable upper
> (not technically part of the container image layers).
> I don't see what it has to do with the read-only stack for layers one
> might want to create especially for a composefs use case.
> Though on this topic personally I think it can often make sense to
> perform some "eager" flattening of images in userspace, but that's a
> metadata-only operation (in userspace) and has nothing to do with the
> in-kernel optimization of metacopy (which is about optimizing when
> userspace dynamically changes metadata on disk).
I think this misses the question. There are two things in play here
that are sort of handled by the same thing. The redirects from lower to
data-only, and the metadata-change-avoids-copy-up optimization.
However, they are currently enabled/disabled by the same option
(metacopy).
The problem here is that if metacopy is on in general, then a writable
upper can also use it for general rewrites, and this is considered
problematic:
* Following redirects can have security consequences: it's like
* a symlink into the lower layer without the permission checks.
* This is only a problem if the upper layer is untrusted (e.g
* comes from an USB drive). This can allow a non-readable file
* or directory to become readable.
*
* Only following redirects when redirects are enabled disables
* this attack vector when not necessary.
So, I think the question is about whether to split these two options so
we can allow only the lower => data-only redirect, without enabling all
the copy-up optimization, and whether there are cases even with
composefs where the copy-up optimization is useful. (And there are, but
they are not necessarily super important.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=
Alexander Larsson Red Hat,
Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
He's an old-fashioned vegetarian master criminal moving from town to
town, helping folk in trouble. She's a bloodthirsty foul-mouthed snake
charmer with an incredible destiny. They fight crime!
