[libvirt] [PATCH] Default to qemu:///system if accessible

Soren Hansen soren at ubuntu.com
Mon Sep 6 12:53:41 UTC 2010


On 06-09-2010 14:18, Daniel P. Berrange wrote:
>> On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be 
>> worried about that? A quick glance in there doesn't reveal anything
>> that I'm uncomfortable disclosing.
> The /etc/libvirt directory itself should be 0700 though,

Nope, it's 0755. :( I'll look into getting that fixed.

> since various files under that location include passwords (qemu.conf,
> secrets/*, qemu/*xml, lxc/*xml, uml/*xml). We don't currently have
> any passwords in libvirtd.conf itself, but its certainly possible
> this might change in the future. While it is possible to rely on
> getting each individual file there to have correct permissions, IMHO
> it is safer to make the /etc/libvirt directory 0700

Makes sense. Thanks for pointing this out. I've never used passwords in
any of these files myself, so I never really gave it much thought :(

>> Assuming I can determine that a given user is authorized to manage 
>> the systemwide libvirtd, would you agree that that is the one 
>> they're most likely to want to access? I simply cannot think up a 
>> realistic example use case where someone has this privilege, but 
>> actually wants to access qemu:///session.
> No, I don't agree. I already mentioned the reasons why it is 
> desirable to run within the user session - SDL, audio, disk 
> permissions, and to add another one gnome-keyring integration for 
> qcow2 passwords which is a future feature we'd like for the secrets 
> driver. IMHO if we are to get better integration into the user's 
> desktop experiance, then having both libvirtd & the VMs running in 
> the user's context, rather than a separate context is key.

Yes, of course, when qemu:///session gets this smart and cool you will
want to access qemu:///session by default. At /exactly/ the same time,
the motivation for setting yourself up with access to qemu:///system
disappears. When that motivation is gone, any admin worth his salt will
immediately revoke said access (in the shared scenario) (since it's a
gaping security hole) and voilà, libvirt will go back to using
qemu:///session by default.


-- 
Soren Hansen
Ubuntu Developer
http://www.ubuntu.com/




More information about the libvir-list mailing list