Open cgwalters opened 4 months ago
I just chatted with @germag about this yesterday as well.
I'd prefer requiring root privileges rather than spinning up a podman machine on Linux. Maybe we find a way to not require root, which would be perfect.
I'd prefer requiring root privileges rather than spinning up a podman machine on Linux.
Mmm. I don't think we should require root so much as access to libvirt - now in reality, I think full unrestricted qemu:///system
libvirt access can probably be elevated to execute arbitrary code on the host, but it's much less obvious than just sudo
- and it's harder to break things accidentally.
Note that if we started using qemu:///system
it would raise the interesting topic of how to get the container images from the user's container storage into a qemu:///system
VM. Unless of course we just say you need to build containers as root too...which to be clear, some people will reasonably want to do.
Here's the way I would put it: there's two totally reasonable ways to want to use the system, and in the limit we probably need to support both:
/dev/kvm
- target status quo for this project todayqemu:///system
for libvirt, and podman as root. (edit: though to be clear in this scenario, because most clouds with the exception of e.g. GCE don't support nested virt, using qemu:///system
is still going to be full emulation, with all the caveats that apply to that (there are a lot)) so the realistic scenario is mostly "build container image", "do sanity checks with full qemu emulation", "spawn real separate cloud VMs for further testing"in reality, I think full unrestricted qemu:///system libvirt access can probably be elevated to execute arbitrary code on the host, but it's much less obvious than just sudo
I think libvirt maintainers consider the 2 to be equivalent (root access and qemu:///system access). It's for example easy to use libvirt storage pool/volume API to read/write to files in arbitrary places (though selinux could block some of these)
I tried 3 different approaches, and I was able to remove (or reduce) the podman-machine requirement, 1 requires root and two virtualization:
1 - Running as root
This will require a new option/command like --from-user <user>
so
we can spawn a new sudo podman-bootc --from-user myuser run ...
,
the user can add podman-bootc to the sudoers file, to avoid entering the password.
We will do something like:
# Create a new mount and pid NS
unshare -mpf --mount-proc # we need a pid NS to "trick" bootc to enter the mount NS
mount --bind -o ro,X-mount.idmap=<user id map> /home/$USER/.local/share/containers/storage /usr/lib/containers/storage
podman run --rm --privileged --pid=host --security-opt label=type:unconfined_t -v /dev/:/dev -v .:/output bootc ...
Pros:
Cons:
/usr/lib/containers/storage
is configured in fedora as an additional image storage, but not in centos (don't know in other systems)2- Using crun-krun It doesn't require root password:
podman run --runtime=krun \
-v ~/.local/share/containers/storage:/usr/lib/containers/storage
...
<image> bootc install ...
Pros:
Cons:
3- Using podman-machine only to run the installation
It doesn't require root password.
We need to run virtiofsd inside a user namespace, and mount the
user image storage ~/.local/share/containers/storage
to the
system image storage /usr/lib/containers/storage
.
This requires changes in podman-machine.
We still use podman-machine, but the images will be stored in the host
Pros:
Cons:
I think we can support 1 and 2. I'll start implementing 1, and send a PR to libkrun to support btrfs. Btw, running directly as a root will also be supported.
- Using crun-krun
I like this one!
We'd like to support Linux without
podman machine
.Other discussions: