install: Read --root-ssh-authorized-keys before changing mounts

[ericcurtin]

Problem

prepare_install() mounts a tmpfs over /tmp and mirrors the host's /var/tmp, and only afterwards reads the --root-ssh-authorized-keys file. A file bind mounted into the install container under /tmp is hidden by then:

podman run ... -v ./authorized_keys:/tmp/authorized_keys:ro <image> \
    bootc install to-existing-root --root-ssh-authorized-keys /tmp/authorized_keys
error: Installing to filesystem: Reading /tmp/authorized_keys: No such file or directory (os error 2)

The file is visible via podman run ... cat /tmp/authorized_keys, so this is confusing.

Change

• Read the file before any mount changes.
• prepare_install() may re-exec (unshare, SELinux install_t) and run again with the tmpfs in place, so carry the content to the child via the environment with a small bootc_utils::reexec helper used by both re-exec sites. This avoids mutating our own environment, which is not thread safe.
• Integration test now mounts the key file under /tmp to cover this.
• Preparatory commit: just package pulls the base image with retries (fedora-46 job failed on a quay.io EOF).

Testing

Fedora 44 aarch64, SELinux enforcing (exercises the install_t re-exec), key file bind mounted at /tmp/authorized_keys:

• bootc 1.16.10: install to-disk --via-loopback ... --root-ssh-authorized-keys /tmp/authorized_keys fails as above.
• With this branch: install completes and /etc/tmpfiles.d/bootc-root-ssh.conf contains the keys.
• cargo test -p bootc-lib --lib, cargo test -p bootc-internal-utils --lib, cargo fmt --check pass.

Generated-by: AI
I hit this on real hardware, reviewed the change and tested it end to end as above.

[Johan-Liebert1]

Logic looks good to me. Could you please sign off your commit as we require a Signed-off-by: <email> line at the end of commit messages

[Johan-Liebert1]

We should make sure it's UTF-8 compatible here itself

[ericcurtin]

Switched to std::env::var(), so the value is a String (UTF-8 enforced by the type) and a non-UTF-8 value is a proper error. The value we write is also a String from read_to_string, so it is UTF-8 by construction.

[Johan-Liebert1]

We only ever call this from one thread so I'm sure if the mutex is required. Also, not a fan of this being a global var. We should only ever re-exec when we are installing, so putting this in prepare_install would make sense and passing in the vector of env vars to reexec_with_guardenv as an extra_args param?

[cgwalters]

We need a mutex or equiv around any static, no problem with that from my PoV.

Also, not a fan of this being a global var.

Yes, but doing it differently would require threading this state from the install code into the lsm code...doable but ugly in a different way.

BTW I would generalize this slightly and e.g.:

• Define a struct we can serialize to JSON of stuff we need to save between re-exec
• In the install path, gather that state before we re-exec
• Serialize it to a memfd
• Set an env var _BOOTC_INSTALL_REEXEC_STATE
• Deserialize it early in the install path

[ericcurtin]

Kept the global per Colin (threading it from install into lsm was the alternative), but folded the env application together with the argv/argv0 setup into a single prepare_reexec() used by both re-exec sites, so the duplication there is gone too, plus a unit test.

On the memfd/JSON generalization: set_reexec_env is already generic over key/value, and the only payload today is a small text file, so I left the env approach for now. Happy to move to a memfd-backed struct if we grow more state to carry across re-exec (or if key files near the 128KiB per-env-string limit turn out to be a real concern).