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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org