On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: > 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? > Speaking personally and as a user here, I think qemu://session is a good thing, I think the process of giving users elevated permissions to use qemu+KVM has been a bad thing for a while now and any attempts at correcting this behaviour is a positive step.
If someone is in an environment where they need to manage the system qemu instance (i.e. production environments) then I would imagine that they would be aware that they need to connect 'somewhere else'. If the environment variable suggested before already exists (sorry couldn't tell) then that is enough to allow those companies to change the default behaviour. My 2 cents. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
