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

Soren Hansen soren at ubuntu.com
Mon Sep 6 11:07:34 UTC 2010


On 06-09-2010 12:24, Daniel P. Berrange wrote:
> On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
>> On 06-09-2010 11:17, Daniel P. Berrange wrote:
>>> Our goal is to improve qemu://session's networking such that
>>> this isn't a reason to use qemu://system anymore
>> Fair enough, but when that happens, I'm supposing people won't have
>> access to the system-wide UNIX socket anymore.
> No, we won't change access to the system instance, the policy for 
> that is already configurable per-host by admins if they so desire.

Yes, that's what I meant. If qemu:///session turns useful enough, admins
won't give users access to the privileged UNIX socket.

>> I disagree. In both of those cases, I'd be surprised if people
>> were able to access the privileged libvirtd socket. In the former
>> case, if people generally had access to the systemwide libvirtd
>> instance, I'd assume that was because that was the one they were
>> supposed to use for their shared development stuff. In the latter
>> case, with that sort of access, I could have full root shell access
>> within minutes, so that'd be a pretty big security fail.
> You are equating access to the UNIX socket, with authorization to
> the unix socket.

Indeed I am.

> With PolicyKit auth enabled by default, the UNIX socket is mode 0777 
> at all times, but this does not imply that all users are able to use 
> it. They can connect, but if PolicyKit denies them, their connection 
> will be dropped by the server.

Fascinating. I had no idea. That's a very convincing argument :)

What if I could come up with a check for whether the user would be
authorized to access the socket? Like including a auth_unix_rw == "none"
condition in the check? Would that change your view at all?

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




More information about the libvir-list mailing list