On 01/06/2011 11:00 AM, Neil Wilson wrote:
Having looked through this, I'm thinking that the simplest thing that would be useful at the moment is simply to have an option in the /etc/libvirt/qemu.conf that adds the acl option to the vnc switch in qemu.
It means that user will have to manipulate the acls directly via the monitor command for the time being until the access layer is designed, but at least you would be able to use acls on a machine launched by libvirt ('change vnc' doesn't appear to activate acls unless the option is active on the command line to start with.).
I can't find a way of doing it with 'qemu:commandline' either - since it is an option to an existing switch.
When we first designed qemu:commandline, we debated about making it smart enough to allow rewriting of existing arguments (rather than only allowing addition of new arguments). This definitely sounds like a use case worth revisiting that situation, and enhancing qemu:commandline to have more features.
So I'm thinking a new option in qemu.conf (vnc_acl) which would add ',acl' to the vnc switch on the qemu command. By default this would bar access to VNC until you'd issued monitor commands to manipulate the access lists.
The option only really makes sense if either vnc_tls_x509_verify or vnc_sasl is set as well, so it may be worth only activating 'acl' in the code if either of those two are also on.
Should this be a per-XML setting, rather than a global qemu.conf setting? Is this something that is forward-looking (ie. once we also have an access layer designed, will it still make sense to keep and honor the qemu.conf setting), or is it enough of a hack that we should instead try to resolve it via the qemu:commandline approach (where we've explicitly documented that use of the interface is the approved way to do hacks in the absence of proper libvirt support)? It's definitely a hack that would let us get to the point o -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org