On Thu, Mar 9, 2023 at 4:26 PM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Thu, Mar 9, 2023, at 9:59 AM, Miklos Szeredi wrote: > > On Wed, 8 Mar 2023 at 16:29, Alexander Larsson <alexl@xxxxxxxxxx> wrote: > >> > >> As was recently discussed in the various threads about composefs we > >> want the ability to specify a fs-verity digest for metacopy files, > >> such that the lower file used for the data is guaranteed to have the > >> specified digest. > >> > >> I wrote an initial version of this here: > >> > >> https://github.com/alexlarsson/linux/tree/overlay-verity > >> > >> I would like some feedback on this approach. Does it make sense? > >> > >> For context, here is the main commit text: > >> > >> This adds support for a new overlay xattr "overlay.verity", which > >> contains a fs-verity digest. This is used for metacopy files, and > >> whenever the lowerdata file is accessed overlayfs can verify that > >> the data file fs-verity digest matches the expected one. > >> > >> By default this is ignored, but if the mount option "verity_policy" is > >> set to "validate" or "require", then all accesses validate any > >> specified digest. If you use "require" it additionally fails to access > >> metacopy file if the verity xattr is missing. > >> > >> The digest is validated during ovl_open() as well as when the lower file > >> is copied up. Additionally the overlay.verity xattr is copied to the > >> upper file during a metacopy operation, in order to later do the validation > >> of the digest when the copy-up happens. > > > > Hmm, so what exactly happens if the file is copied up and then > > modified? The verification will fail, no? > > I believe the intention here is to deploy this without a writable upper dir by default, so there's no copy-up, the calling code just gets -EROFS. The intention is to also use this to push the podman/docker/kube style ecosystem away from "mutable by default" container images i.e. to "readonlyRootFilesystem" by default (xref https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ ) That is indeed some of the primary usecases for this. However, that doesn't mean it is not useful also for other usecases. > But yes, some scenarios will still want a writable upper dir for default, as long as that writable upper dir is discarded across reboots (to aid in anti-persistence). Maybe this needs to be configurable; I could imagine people wanting a writable upper dir, but to still enforce fs-verity for *existing* content. Other cases may want the logic to just strip away the fsverity xattr across copy-up in this case. I've been chatting with amir in github about this, and yes, we can have options that make this useful also with an upper. I'll try to post a new version with this tomorrow. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
