On Mon, 30 Sep 2019 at 21:05, Bruno Haible <bruno(a)clisp.org> wrote:
Daniel P. Berrangé wrote:
> > For what purpose is libvirt or QEMU using setgroups()? What goes wrong if
> > setgroups() fails?
On macOS, as far as I can see, everything works as expected without it.
So not sure if it's actually needed?
> QEMU potentially needs access to files owned by a supplementary
group.
> On Linux for example, /dev/kvm is often owned by 'kvm' group, but the
> 'qemu' user on Fedora has 'qemu' group as its primary group. So
QEMU
> would be unable to open /dev/kvm without the setgroups call to set up
> supplementary groups.
Ah, it's libvirt which calls setgroups and qemu which needs the groups.
Then my suggested workaround that consists of overriding setgroups() and
open() won't work.
> > - Is using the first 16 groups and ignoring the extra ones an acceptable
> > solution?
>
> Certainly that's better than just ignoring groups entirely, as it will
> work for many more cases, even if not perfect.
Hmm. If the group of /dev/kvm comes at 17th group, it will still not work.
I.e. it will be unreliable.
Then, how about if libvirt collects the set of groups that qemu might need
for accessing devices (surely less than 16), then fills up the remaining
up to 16 slots with secondary groups? Admittedly it makes qemu less
self-contained. But given that setgroups() works only for root on macOS [1]
I see no better way.
Note that /dev/kvm is for linux and does not exist on macOS.
Unless we identify specific devices on macOS that qemu requires access
to, then something like the following might work?
https://github.com/furlongm/libvirt/commit/01a1d3d0e37c7f81a04da2e9707ac1...
Seems to work correctly for me (virsh capabilities now returns the
correct output, and VMs run).
--
Marcus Furlong