[WIP] prepare-root: add support for read-only ostree target

[TristanCacqueray]

This change tries to make ostree image more immutable by supporting
read-only rootfs. When the ostree target is suffixed with ':ro', then
prepare-root remount sysroot as RDONLY and it creates overlayfs for
/etc and /var so that the system can boot.

[papr-bot]

Can one of the admins verify this patch?

[TristanCacqueray]

This is an exploratory experiment to make ostree image more immutable and enable further test of dm-verity as an image backend. This change also requires "/dev/mapper/fedora-root / ext4 defaults,ro 1 1" otherwise systemd remount / as RW, and we should ensure /var/log is mounted to a persistent storage.

[rh-atomic-bot]

Can one of the admins verify this patch?
I understand the following commands:

• bot, add author to whitelist
• bot, test pull request
• bot, test pull request once

[cgwalters]

Did you see https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/ ?

How are you planning to do updates with this model?

[TristanCacqueray]

Yes, thank you for writing this post.

Well I am still learning out how ostree works, thus I'm not sure if this prepare-root change is the right path for such implementation. Perhaps we could check if deploy_path is a loop file (like squashfs) or a block-device. Though I don't know how the pull command would work with such backend.

I guess the next step would be to go for coreos/rpm-ostree#702 so that we can at least create user.

[cgwalters]

One important thing to know about overlayfs is that it doesn't stack, so with this approach you wouldn't be able to use e.g. docker or podman out of the box (although both have configurable VFS backends the performance drops greatly).

It seems simpler to just have /var be a tmpfs very early on...we in fact have some code to do that I believe.

Do you still want to pursue this? I'm not so sure it makes sense without a model for how in-place updates work.

[TristanCacqueray]

Agreed this need a model for in-place updates. IIUC dm-verity would need a couple of block device to install the current and the next signed image. Moreover It seems like the signing would need to happen locally to accommodate the current ostree storage and support package layering.

I am not sure how much work is needed and we could close that PR until then since that was just the easy part.

[cgwalters]

I think IMA is a closer alignment to ostree. See also coreos/rpm-ostree#1883

See also discussion on fs-verity.

Closing (but without prejudice - feel free to reopen if you have some more concrete plans for how dm-verity and ostree could intersect).