install: switch to doing dynamic mounts

[cgwalters]

Moving this to a targeted issue from #380

Basically let's switch to using dynamic mounts for e.g. /dev and /var/lib/containers etc. This would help drop out a lot of the boilerplate from our install invocations.

[omertuc]

Can we drop --security-opt label=type:unconfined_t too? Doesn't the re-exec take care of that?

I tried looking into dropping --pid=host but the more I looked the more impossible it seemed. Especially with #919 which heavily relies on it. It does feel like it must be possible, because with --privileged we can technically do anything, but short of (in theory) patching the kernel in memory to help us escape the pid namespace I couldn't come up with anything

Anyway without --security-opt label=type:unconfined_t we're now only at:

podman run --privileged --pid=host <image> bootc install to-existing-root

Quite memorable

With ENTRYPOINT /usr/bin/bootc we could even get rid of bootc, and maybe alias install to-existing-root to root-install?

podman run --privileged --pid=host <image> root-install

And maybe it's a bit of a ridiculous idea but if we can selfishly convince the podman project to bundle/alias --privileged --pid=host into something like --system, -s or --host (doesn't have to be so specific to just these two to cover just our use case - could also include things like --net=host, --ipc=host, etc) then it'll just be:

podman run -s <image> root-install

or

podman run --host <image> root-install

[omertuc]

(Sorry I'm kinda discussing BIFROST-532 instead of #826)

[cgwalters]

(Sorry I'm kinda discussing BIFROST-532 instead of #826)

Yeah it's fine, they are related at least.

I tried looking into dropping --pid=host but the more I looked the more impossible it seemed. Especially with #919 which heavily relies on it. It does feel like it must be possible, because with --privileged we can technically do anything, but short of (in theory) patching the kernel in memory to help us escape the pid namespace I couldn't come up with anything

Yeah, I don't know either. I think the most general fix would be spec'ing out something where with --privileged the container runtime is defined to give the invoked process a pidfd for the invoking process or so? Then we can enter that process's pid, mount etc. namespaces.

Anyways though, let's just keep this one focused on the mounts for now; I'll file trackers for the other angles.

[cgwalters]

I took a look at --security-opt in #928 - but changing that will become a conflict fest with #919 so let's get that in first please.