Hi Daniel,
Ok, got it about libvirt being root and being able to change any ownership on files and devices. As we run our kata-runtime as root, it can exactly do the same thing as libvirt does, and I'd like to understand the details about the way changing ownership works.
Does libvirt change the ownership of the device back to its initial ownership once it gets "released" by Qemu (when Qemu terminates) ?
Also, the fies created will be owned by the non-root user being chosen, which modifies the security associated with those files. When Qemu runs root, only root can access/modify them on the host, but by running Qemu as non-root, they will be more accessible since they won't be owned by root.
Thanks, Sebastien ________________________________________ From: Daniel P. Berrangé [berrange@redhat.com] Sent: Wednesday, July 18, 2018 12:14 AM To: Boeuf, Sebastien Cc: Stefan Hajnoczi; kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] Improving isolation in Kata
On Tue, Jul 17, 2018 at 10:25:53PM +0000, Boeuf, Sebastien wrote:
Hi Stefan, Daniel,
Thanks for the feedback here. I have just tried the virtfs-proxy-helper and it works like a charm, allowing me to run Qemu from a non root user. Now, I haven't tried this yet, but I wanted to know if you thought about any reason using virtio-net-pci would not work by using the vhost backend like this: -netdev tap,id=network-0,vhost=on,vhostfds=3:4:5:6:7:8:9:10,fds=11:12:13:14:15:16:17:18 -device driver=virtio-net-pci,netdev=network-0,mac=02:42:ac:11:00:02,mq=on,vectors=18
Yes, libvirt supports passing multiple FDs for vhost, and setting mq/vectors properties.
Same question about block devices. We're doing heavy uses of virtio-scsi in order to share a block device (our container rootfs) with the guest. Is it possible to run Qemu non root in this case ? Should I put the user running Qemu in the disk group so that Qemu can read/write to this block device ?
What happens is that the libvirtd daemon is running as root. When launching a guest, it thus has privileges to change ownership of the block device so that QEMU can access it while running as non-root. So there's no need to change block device permissiosn or set group membership - libvirt will take care of changing it for you.
Last use case is VFIO for device passthrough. After we unbind the device from its driver on the host, should we change the ownership of the device created (something like /dev/vfio/X) after it has been bound to vfio-pci driver ?
Again, libvirt would take care of any permissions change that is required.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|