Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install: switch to doing dynamic mounts #826

Open
cgwalters opened this issue Oct 14, 2024 · 2 comments · May be fixed by #919
Open

install: switch to doing dynamic mounts #826

cgwalters opened this issue Oct 14, 2024 · 2 comments · May be fixed by #919
Labels
area/install Issues related to `bootc install` enhancement New feature or request

Comments

@cgwalters
Copy link
Collaborator

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.

@cgwalters cgwalters added area/install Issues related to `bootc install` enhancement New feature or request labels Oct 14, 2024
cgwalters added a commit to cgwalters/bootc that referenced this issue Nov 25, 2024
We're looking again at the ergonomics of `bootc install to-existing-root`.
This uses the "mounting into mount namespaces" from the new
mount API to automatically set up `/dev` and `/var/lib/containers`
if they weren't provided to `podman run`, which shrinks what's
needed a bit.

Closes: containers#826

Signed-off-by: Colin Walters <[email protected]>
cgwalters added a commit to cgwalters/bootc that referenced this issue Nov 25, 2024
We're looking again at the ergonomics of `bootc install to-existing-root`.
This uses the "mounting into mount namespaces" from the new
mount API to automatically set up `/dev` and `/var/lib/containers`
if they weren't provided to `podman run`, which shrinks what's
needed a bit.

Closes: containers#826

Signed-off-by: Colin Walters <[email protected]>
@omertuc
Copy link
Contributor

omertuc commented Nov 27, 2024

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
Copy link
Contributor

omertuc commented Nov 27, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/install Issues related to `bootc install` enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants