[Pkg-libvirt-maintainers] Bug#764849: Bug#764849: Bug#764849: Bug#764849: Bug#764849: libvirt-daemon-system: user libvirt-qemu vs. groups libvirt[-qemu]|kvm and VNC socket access

Guido Günther agx at sigxcpu.org
Sun Oct 12 17:55:31 UTC 2014


On Sun, Oct 12, 2014 at 07:44:10PM +0200, Guido Günther wrote:
> On Sun, Oct 12, 2014 at 07:17:02PM +0200, Christoph Anton Mitterer wrote:
> > 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.
> 
> ...as long as the console are "routed" through libvirt (e.g. xen used
> to work this way or lxc).
> 
> > 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.
> 
> Because qemu creates them VNC socket..
> 
> > A solution would be probably needed upstream (e.g. that libvirtd changes
> > the permissions of the socket 
> 
> Yeah, that's why we should keep it open.

Forgot to mention that you're probably looking for 

virDomainOpenGraphicsFD

Cheers,
 -- Guido



More information about the Pkg-libvirt-maintainers mailing list