Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapt usroverlay for composefs #3177

Closed
cgwalters opened this issue Feb 15, 2024 · 4 comments · Fixed by CentOS/centos-bootc-dev#32
Closed

adapt usroverlay for composefs #3177

cgwalters opened this issue Feb 15, 2024 · 4 comments · Fixed by CentOS/centos-bootc-dev#32
Labels
area/composefs Issues related to composefs

Comments

@cgwalters
Copy link
Member

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

@cgwalters cgwalters added the area/composefs Issues related to composefs label Feb 15, 2024
@alexlarsson
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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 added a commit to cgwalters/centos-boot-dev that referenced this issue Feb 28, 2024
This just enables composefs.

Per discussion for now we will just document the existing
`bootc usroverlay` etc., but we also need to fix ostreedev/ostree#3177
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/composefs Issues related to composefs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants