On Tue, Mar 06, 2007 at 08:46:24PM +0000, Mike Cohler wrote: > Adam Tkac <atkac <at> redhat.com> writes: > > > features than actual "real desktop" servers. So two programs could be > > removed and one added => cost of maintaining and bugfixing could be > > lower. In next stage we could discuss about standardized RFB protocol > > library which could be used by all vnc servers in distro. In the end we > > could have one rfb library which will be used by all servers (and > > viewers), one real server, one virtual server and X module. What do you > > think about this idea? Since we're on the subject of VNC servers, its a good time to bring up the question of virtualization. With Xen in the mix there are actually 2 further VNC server implementations in Fedora... - Xen para-virtualized guest console server - QEMU / KVM / Xen fully-virtualized guest console server The former is currently based on libvncserver which turned out to be an really bad mistake. The code is horribly complicated / obtuse and has completely unsafe use of pthreads synchronization primitives. The QEMU VNC server is a from sratch impl of the RFB protocol which is directly part of the QEMU codebase. It is my intention that the current Xen paravirt VNC server will be re-written to use more-or-less the same code as the current QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000. Now this isn't directly relevant, since the code isn't really suitable for turning into a standalone VNC server. I just wanted to point out that you should be wary of picking libvncserver as the basis of a shared RFB impl in its current form, since the codebase isn't all that nice to work with. The whole discussion of merging VNC servers though misses out the most critical shortcoming in VNC - it has a non-existant security model. All traffic is clear-text on the wire, and the authentication is trivially brute-forced. Tunnelling it over SSH is really just a band-aid, because even with it restricted to listen on 127.0.0.1 any local user can still trivially compromise any other user's session For the virtualization arena, tunnelling over SSH is out of the quesiton because integrity of the host system is too important. You don't want to have to give out login accounts to the host just so that a user can access the guest virtual console. So for Xen / QEMU I am currently working on implementing native SSL support in their respective VNC server impls, based on the protocol defined by VeNCrypt. I expect this work to arrive some time in the Fedora 8 dev cycle, which is when we hope to have full-remote management capabilities for Xen / QEMU / KVM. The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that supports encryption aside from SSH tunnelling - not a huge problem since virt-manager has an embedded GTK VNC widget which can do the job, but it would be nice to have a standalone viewer for virtual machine consoles. So if we're thinking of long term Fedora VNC development plans, we should make sure encryption / authentication is on the list for both client & server. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
