From 833dda41365b2ea830e1811b71be4b807e7f2303 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 14 Apr 2025 08:49:37 -0400 Subject: [PATCH] docs/filesystem: Explain a little bit more about fsverity - Doesn't apply to LBIs, and actually c/storage has no knob for this - Elaborate a bit on /etc and /var Signed-off-by: Colin Walters --- docs/src/filesystem.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/docs/src/filesystem.md b/docs/src/filesystem.md index d7171703..e4143a37 100644 --- a/docs/src/filesystem.md +++ b/docs/src/filesystem.md @@ -287,9 +287,26 @@ mechanism to check the integrity of the upper composefs. For more information about this, see [this tracking issue](https://github.com/bootc-dev/bootc/issues/1190). -### Enabling fsverity across upgrades +Note that the default `/etc` and `/var` mounts are unaffected by +this configuration. Because `/etc` in particular can easily +contain arbitrary executable code (`/etc/systemd/system` unit files), +many deployment scenarios that want to hard require fsverity will also +want a "transient etc" model. + +### Caveats + +#### Does not apply to logically bound images + +The [logically bound images](logically-bound-images.md) store is currently +implemented using a separate mechanism and configuring fsverity +for the bootc storage has no effect on it. + +#### Enabling fsverity across upgrades At the current time the integration is only for installation; there is not yet support for automatically ensuring that fsverity is enabled when upgrading from a state with `composefs.enabled = yes` to `composefs.enabled = verity`. +Because older objects may not have fsverity enabled, +the new system will likely fail at runtime to access these older files +across the upgrade.