We've had reports treating bootc's default deference to
containers-policy.json as a vulnerability, fix this by having
a clear policy.

Assisted-by: AI
Signed-off-by: Colin Walters <[email protected]>

We sign and boot systemd-boot directly with our own Secure Boot test
key (and for sealed images, the UKI itself); shim's chain of trust is
never used in either case. Remove shim in the same rpm -e call as
bootupd so it doesn't linger in test images, mirroring the same
cleanup done in redhat-cop/rhel-bootc-examples#18.

Package name varies by arch (shim-x64 on x86_64, shim-aa64 on
aarch64), and neither package is guaranteed to be present, so detect
the arch and only remove what's actually installed.

Assisted-by: AI
Signed-off-by: Colin Walters <[email protected]>

Signed-off-by: bootc-bot[bot] <225049296+bootc-bot[bot]@users.noreply.github.com>

Signed-off-by: bootc-bot[bot] <225049296+bootc-bot[bot]@users.noreply.github.com>

cap-std refuses to follow absolute symlinks since they would escape the
sandbox, returning PermissionDenied. When /etc/containers/policy.json is
a symlink to e.g. /usr/share/containers/policy.json, this caused policy
resolution to silently skip the file.

Switch to `cap_std_ext::RootDir` that handles the above semantics by
itself

Test written by Claude

Fixes: #2339

Signed-off-by: Pragyan Poudyal <[email protected]>

We want to support at least read-only operation when mounted from
a physically read-only medium (like a squashfs/EROFS for /sysroot).

Check the backing block device status, and propagate its read-only
state up.

Generated-by: AI
Signed-off-by: Colin Walters <[email protected]>

Signed-off-by: bootc-bot[bot] <225049296+bootc-bot[bot]@users.noreply.github.com>

The composefs-rs update added a required OciTransformOptions parameter
to generate_boot_image, create_filesystem, and read_container_root.
Pass Default::default() at all call sites to preserve the previous
behavior (no xattr filtering).

Assisted-by: AI
Signed-off-by: John Eckersberg <[email protected]>

Per previous meeting, we have an ongoing conflict between
the 1 week schedules for both things.

Signed-off-by: Colin Walters <[email protected]>

It turned out that a systemd version skew caused systemd-tmpfiles
to rerun, which created `/root/.ssh` - and that triggered our
tmpfiles lint.

We need to handle the symlink aliases more strongly - do that
by walking the generated paths and comparing device/inode.

Assisted-by: AI
Signed-off-by: Colin Walters <[email protected]>

Signed-off-by: bootc-bot[bot] <225049296+bootc-bot[bot]@users.noreply.github.com>

#1896

Signed-off-by: John Eckersberg <[email protected]>

…atest

Agentic investigation points at teemtee/tmt#5068
as a recent source of flakes.

Roll back to an earlier version, and pin to it which can be bumped
via renovate.

Signed-off-by: Colin Walters <[email protected]>

If we have a UKI digest mismatch error, we now print the dumpfile diff,
if a dumpfile is present at `/boot/$kver.dump`

Closes: #2313

Signed-off-by: Pragyan Poudyal <[email protected]>

Signed-off-by: Pragyan Poudyal <[email protected]>

Use the `dump_files` API to get the external dumpfile object from
object store

Signed-off-by: Pragyan Poudyal <[email protected]>

Signed-off-by: bootc-bot[bot] <225049296+bootc-bot[bot]@users.noreply.github.com>

`bootc install to-filesystem` writes
`systemd.mount-extra=UUID=<ESP>:/boot:auto:ro` into the deployment
cmdline; systemd's fstab-generator then mounts /boot ro at boot. Every
subsequent `bootc status` failed with

    error: Status: Mounting /dev/vda1: Device or resource busy (os error 16)

and any code path that writes the ESP (BLS install, UKI install, gc)
would hit the same EBUSY on a pre-mounted host.

Split the ESP-mount primitive into two intent-typed helpers, and thread
the choice through BootedStorage so callers pick their access mode
explicitly:

- `mount_esp_readonly` for `bootc status` — reuses an existing mount
  as-is via `open_tree(OPEN_TREE_CLONE)`, safe because we're not
  writing.
- `mount_esp_writable` for install/upgrade/gc — must produce a mount
  that supports writes even when the ESP is pre-mounted ro. Its
  implementation is refined in a follow-up commit; the primary
  purpose of this commit is establishing the typed API surface.

`BootedStorage::new` grows an `EspAccess` argument; `status::get_host`
passes `ReadOnly`, `cli::get_storage` passes `ReadWrite`. The raw
`mount_esp` primitive is now module-private and only reachable through
the typed wrappers.

Also adds `bootc_mount::find_mount_target_by_source(dev)`, a walk over
the mountinfo tree that returns the existing target path for a source
device (or None), plus a table-driven unit test covering top-level,
nested, absent, empty, and deeply-nested mountinfo shapes.

Verified live on QEMU x86_64 (systemd 261.2, linux-qemu-6.18-bootc,
/boot mounted ro via systemd.mount-extra). Before: `bootc status`
fails with EBUSY. After: full YAML output and JSON output both work.

Assisted-by: Claude (Opus 4.7)

Fixes: #2355
Signed-off-by: Dustin Kirkland <[email protected]>

`open_tree(OPEN_TREE_CLONE)` creates a mount that shares the
original's underlying superblock, and a bind remount only clears the
clone's own `MNT_READONLY` flag, never the shared superblock's
`SB_RDONLY` (`do_reconfigure_mnt()` in `fs/namespace.c` says as much).
So the existing `mount_esp_writable` silently produced a mount that
still failed writes with `EROFS`. Verified with a loopback vfat image.

Fix it to remount the *existing* mount read-write in place instead of
a private clone, the same handling `open_dir_remount_rw` already gives
`/sysroot`. This needs `find_mount_target_by_source` to look up mounts
in the caller's own mount namespace rather than pid 1's, since bootc
already runs unshared by the time these functions are called.

Apply the same fix to `mount_esp_at()`, used during install.

Use `rustix::mount::mount_remount()` directly instead of shelling out
to `mount(8)`, matching the rest of this module.

Assisted-by: AI
Signed-off-by: Dustin Kirkland <[email protected]>

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>