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/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list