On Sun, 2014-10-12 at 09:30 +0200, Guido Günther wrote: > You can change the user running the VM in qemu.conf. Sure :) I saw that but... okay we misunderstand each other I guess.
My idea/understanding was the following: libvirt group - would be intended to be the group, for having permission to talk to libvirt and it's VMs libvirt-qemu - would be intended to be the user/group, that qemu runs under and that image files belong to (for the sake of privilege separation) If it's like that, then one would expect: - normal users shouldn't be added to libvirt-qemu (because they shouldn't need to mess around with qemu directly, and especially they shouldn't be able to access the VM images directly) - if users want to access libvirtd (for creating/starting/stopping/etc. VMs and for connecting to their consoles),... they should be added to libvirt group. But if it's like this, it doesn't work as of now, at least not with socket based VNC, cause the sockets are created by qemu and this with libvirt-qemu owners. A solution would be probably needed upstream (e.g. that libvirtd changes the permissions of the socket files) Alternatively one could say: libvirt group - would be intended to be the group, for having permission to *just* talk to libvirt (i.e. creating/stopping/starting VMs) but *not* to talk to the VMs themselves (i.e. qemu and the consoles) libvirt-qemu - would be intended to be the user/group, for talking to qemu and thus to the consoles On a first glance, I'd say that these semantics are not so nice,... but if this is what is desired, than there would be no bug and we could close it. Unless perhaps adding some line to README.Debian that explains just this behaviour and when users need to be added to libvirt and when to libvirt-qemu groups. :) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
