RFE: Work on Linux even without podman machine

[cgwalters]

We'd like to support Linux without podman machine.

Other discussions:

• Support running from a container #28

[vrothberg]

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.

[cgwalters]

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:

• Unprivileged user (Linux desktop), bare metal hardware with access to /dev/kvm - target status quo for this project today
• Privileged user in a Linux cloud VM (e.g. public/private cloud). Again here while we can build containers without privileges, the only reasonable implementation path today is to require real root privileges to make the filesystems. We might as well encourage building the containers as root too, hence - and can just use qemu:///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"

[cfergeau]

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)

[germag]

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:

• Simple, all the required changes are self-contained in podman-bootc
• A user can put podman-bootc in the sudoers to avoid entering the password

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:

• no root password
• fast boot
• don't need to deal with the VM lifetime, the VM will run for each install
• in the future, we could directly boot the kernel inside the container

Cons:

• an extra bit of work to setup the "additional image storage"
  inside the container, specifically in centos is not configured.
• custom kernel: currently not all the file systems are supported.
  This will change in the near future, Sergio is open to add all the
  required file systems.
• custom kernel: if there is a missing feature (like a file system)
  the user can not change/fix that by himself. This will soon will
  change, and we will be able to select which kernel we want to run

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:

• no root password
• podman-machine is already part of podman

Cons:

• requires changes on podman-machine
• Handling the lifetime of the VM is not clear, should I start it
  and leave it running, should I start it every time, what happens if
  there is already another podman-machine running.

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.

[cgwalters]

• Using crun-krun

I like this one!