Daniel P. Berrange schrieb: > On Thu, Jun 11, 2009 at 11:45:43AM +0200, Christian Weyermann wrote: > >> Daniel P. Berrange schrieb: >> >>> On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: >>> >>> >>>> Daniel P. Berrange schrieb: >>>> >>>> >>>>> On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: >>>>> >>>>> >>>>> >>>>>> Daniel P. Berrange wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hello everybody, >>>>>>>> >>>>>>>> I encountered the following problem. I want my users to only be able to >>>>>>>> connect to their own virtual machines via VNC. Is there any way to do so? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> The VNC authentication setup is currently being done per-host, so there >>>>>>> is no way to define ACLs per-(user,vm) tuple as you describe. >>>>>>> >>>>>>> >>>>>>> >>>>>> What about the VNC password? >>>>>> That's per-VM, isn't it? >>>>>> >>>>>> >>>>>> >>>>> That is true by I don't really consider VNC password to be useful. It is >>>>> utterly insecure. If you want to have plain passwords, then its better to >>>>> use the new SASL authentication method, with its Digest-MD5 plugin. That >>>>> is still not top-grade security, but it is better then VNC password and >>>>> allows configuration of arbitrary Username+pasword pairs.. At which point >>>>> we just need ACLs against the usernames. SASL also provide Kerberos auth, >>>>> where we can do an ACL against the Kerberos principle name. And VeNCrypt >>>>> provides TLS+x509 certificates which you can either layer SASL over again, >>>>> or require client x509 certs and do an ACL against the client CNAME >>>>> >>>>> >>>> Ok, so let me sumarize: It is possible to define username+password pairs >>>> via SASL. SASL can also sync with Kerberos. So the only problem left is, >>>> that there is no way to assign a specific username to a VM. So, what we >>>> need is a plugin, where we have an username and a virtual machine as >>>> input and we need to refuse the connection, if this pair is not valid. >>>> The VNC Server is part of libvirt, so the perfect method to add this >>>> functionallity would be the VNC Servers authenticate or start method. >>>> >>>> However, a Windows user is still not able to connect as there is no >>>> windows vnc client capable of doing SASL. >>>> >>>> >>> GTK-VNC builds on Windows, and so does libvirt. So the intent was that >>> we'd be able to have virt-viewer working on Windows using those two. >>> Oh, when I say Windows, i mean Mingw32 >>> >>> >> Ok, so the other part of the post is correct? So what do you think about >> the effort for implementing this feature? >> > > Well I've had the demo program from GTK-VNC working sucessfully under > Wine, and had virsh successfully working under Wine. So I see no reason > why we virt-viewer should be troublesome to get working. I hope it'll just > be a lot of silly small bugfixes/portability fixes, rather than any large > fundamental problem. Ok, so I have just one question left. What do you think about the effort of implementing the "per VM" authentication feature? This would include VNC and "normal" libvirt access? -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list