[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