prepare-root: add root = transient-ro`

[cgwalters]

In a composefs world, usroverlay isn't wrong, but it's less applicable. We should adapt this to just make a writable overlay for / - or can we actually dynamically reconfigure overlayfs to add an upper? Hmm, that appears to not be possible. I wonder if we should always mount a tmpfs upper, but leave it read-only by default? Then we can trivially remount that tmpfs rw to go from ro to rw.

cc @alexlarsson

[alexlarsson]

Yeah, it is not possible to modify the layer structure of an overlayfs mount after initial mount.

However, I'm not 100% sure you can even modify the upper mount like you propose, because I think overlayfs makes a snapshot of the mount for the upper and lower at the point of mount. Maybe you can always have a writable upper, but make the entire overlayfs mount read-only?

[cgwalters]

Maybe you can always have a writable upper, but make the entire overlayfs mount read-only?

Yeah, this works fine. I guess what I'm somewhat uncertain about is whether we enable that by default...it feels like some use cases will want to be able to statically verify that the rootfs stack is read-only. Hmm...maybe

[root]
transient = "ro"

or something?

Or maybe it's confusing to have separate values for root and composefs and we should add a new key like:

[composefs]
upper = "tmpfs-ro" | "tmpfs-rw"

Dunno...maybe we should actually support a systemd .mount unit embedded in the initramfs to define the composefs upper instead (that would get us out of needing to replicate mount options, filesystem types etc.)

[alexlarsson]

Yeah, having this always on seems a bit weird for a use case like automotive where it brings nothing but increased risk. Thatever we decide it should be possible to at least opt out completely.

[cgwalters]

I am curious though...is there really a huge risk difference between the ability to mount a transient overlayfs on top of the root at runtime, versus making an already extant root's tmpfs writable?

I'm not arguing against the ability to turn it off, to be clear - I'm just thinking that it does make sense to enable by default.

[cgwalters]

This one I think is still relevant, reopening. It'd be easy to do and make it a lot easier for things like rpm-software-management/dnf#2195 to also support RPMs that install to /opt as well (cc containers/bootc#1038 )

However, a downside of having this by default is it makes the story around containers/composefs#360 harder - but probably the people who want to do IPE-style things would just turn it off.