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. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list