ephemeral: Add writable tmpfs overlay over /root/.ssh

[rmsc]

Some fully transient bootc images might have a read-only /root, which breaks ssh key injection. Overlaying a writable tmpfs over /root/.ssh allows the keys to be injected without changing the write permissions for the /root directory or shadowing existing keys.

The implementation mirrors what's currently done for /etc, with an additional bcvk-root-ssh-overlay.service unit embedded in the CPIO archive that gets appended to the initramfs. Since there might be secrets in /root/.ssh, we're ensuring the overlay directories are created with mode 0700.

In conventional bootc images, /root is a symlink to /var/roothome, which is created by tmpfiles.d after the pivot to the final root filesystem. Because the target directory doesn't exist during the initramfs stage, attempting to mount an overlay over /root/.ssh would fail. But since /var/roothome is writable in these systems, the overlay is unnecessary and can be safely skipped.

Closes: #331

[cgwalters]

Some fully transient bootc images might have a read-only /root, which breaks ssh key injection.

Explain this more? Like /root is not a symlink to /var/roothome but is just a plain directory?

If so...yeah, this seems fine but what I think would ultimately be a lot cleaner here is we write the keys into /run and ensure openssh picks them up from there.

[rmsc]

Some fully transient bootc images might have a read-only /root, which breaks ssh key injection.

Explain this more? Like /root is not a symlink to /var/roothome but is just a plain directory?

Exactly, pure composefs with plain /root and /home directories.

I'm composing a base image like this, with derived images deciding what to mount there. Fully transient images would mount a pure tmpfs and fetch ssh keys on boot, while more "regular" images would likely do a bind mount for /home and an overlay mount for /root.

Maybe something that could later be handled by initramfs-setup via config?

If so...yeah, this seems fine but what I think would ultimately be a lot cleaner here is we write the keys into /run and ensure openssh picks them up from there.

Maybe, but I think this would involve modifying sshd's config (for instance via drop-in). But IIRC it wouldn't work for dropbear, which has the path hardcoded..

[rmsc]

while more "regular" images would likely do (...) an overlay mount for /root.

Which, now that I think of it, might break the .ssh overlay mount :/ any suggestion here?

EDIT: I think it actually satisfies all the kernel overlay requirements, so shouldn't cause any problem.

[cgwalters]

I'm composing a base image like this, with derived images deciding what to mount there. Fully transient images would mount a pure tmpfs and fetch ssh keys on boot, while more "regular" images would likely do a bind mount for /home and an overlay mount for /root.

You mean for the final bootc-installed system? Mount a pure tmpfs...where? Over /root? This relates to bootc's support for fully transient / if you need that.

I guess backing up, while I think we should support with bcvk having /root be a plain directory, is there any reason for your use case you can't just mount a tmpfs over that in your target OS?

[cgwalters]

I think what woudl help for this patch is a ConditionPathIsSymbolicLink=!/root or so to avoid a duplicate overlay for our current Fedora-derivative (at least) base images where /root -> /var/roothome.

[rmsc]

You mean for the final bootc-installed system? Mount a pure tmpfs...where? Over /root? This relates to bootc's support for fully transient / if you need that.

Maybe over /root, but also over /home/someuser while leaving /root read-only.

I think a fully transient / goes in the opposite direction of having a fully locked-down system.

I guess backing up, while I think we should support with bcvk having /root be a plain directory, is there any reason for your use case you can't just mount a tmpfs over that in your target OS?

I considered doing that for debugging, but I'd like to avoid including the mount in the base image. I was injecting a systemd mount unit for ephemeral runs, but that's not supported in libvirt or to-disk.

[rmsc]

I think what woudl help for this patch is a ConditionPathIsSymbolicLink=!/root or so to avoid a duplicate overlay for our current Fedora-derivative (at least) base images where /root -> /var/roothome.

That's a great catch, thanks!

I think the CI is failing because of https://rustsec.org/advisories/RUSTSEC-2026-0173.html, probably worth doing a cargo update?