Re: [PATCH] qemu: don't reject virtiofs for qemu:///session
On 3/29/21 12:52 PM, Ján Tomko wrote:
On a Friday in 2021, Cole Robinson wrote:
> Currently libvirt rejects attempts to use virtiofs with
> qemu:///session. Indeed virtiofs does not have a chance of working
> with typical session usage, because virtiofsd needs multiple linux
> capabilities to perform its job. The only way to do this with out
> of the box qemu packaging is to run virtiofsd as root, so libvirtd
> must run as root, so qemu:///system is required.
>
> But it's possible that a custom environment could setuid or set
> file capabilities on the virtiofsd binary. In this case qemu:///session
> would work fine. This may be an option for kubevirt to help them
> transition to using qemu:///session everywhere
>
> Drop the two pieces that block virtiofs for qemu:///session. Attempts
> to use virtiofs for stock qemu:///session will fail at qemu startup,
> though it's a bit opaque:
>
> error: Failed to start domain 'f32'
> error: internal error: qemu unexpectedly closed the monitor:
> 2021-03-26T16:26:12.459293Z qemu-system-x86_64: -device
> vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0:
> Failed to write msg. Wrote -1 instead of 12.
> 2021-03-26T16:26:12.459317Z qemu-system-x86_64: -device
> vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0:
> vhost_dev_init failed: Operation not permitted
>
That is not a friendly error message for regular users.
Some alternatives come to mind:
* XML element telling libvirt to ignore the check/do not set the UID.
The downside is, that we usually do this via:
<seclabel relabel='no'/>
and the seclabel code makes my head hurt.
No, seclabel shouldn't be used for processes IMO. The fact that we use
an external process should be hidden from user (as an implementation
detail) and therefore libvirt should do all magic necessary so that it
just works (TM). Of course it has capabilities to do so. Otherwise - I'd
say we can expect users to configure all bits necessary.
Also, it might be misleading - does seclabel apply to the process or
perms visible from inside the guest? Wouldn't it recursively chown() the
directory exposed?
* Introduce a QEMU capability for this, that kubevirt could set via
<qemu:capabilities>
https://libvirt.org/drvqemu.html#xmlnsfeatures
I'd rather not do this. Such capability would be useless, the only thing
it would help with is nicer error message.
* Introduce the capability to 50-qemu-virtiofsd.json
* Wait until the lockdown eases up and I finally post the patches
for externally launched virtiofsd
https://bugzilla.redhat.com/show_bug.cgi?id=1855789
How are you dealing with this situation in your patches? I mean, what if
externally launched virtiofs doesn't have enough permissions?
Michal