On Fri, Dec 12, 2014 at 01:24:57PM +0100, Peter Krempa wrote:
On 12/12/14 12:49, John Ferlan wrote:
On 12/12/2014 04:04 AM, Chunyan Liu wrote:
Signed-off-by: Chunyan Liu <cyliu@suse.com> --- src/remote/remote_driver.c | 2 +- src/remote/remote_protocol.x | 13 ++++++++++++- 2 files changed, 13 insertions(+), 2 deletions(-)
struct remote_domain_send_process_signal_args { remote_nonnull_domain dom; hyper pid_value; @@ -5550,5 +5555,11 @@ enum remote_procedure { * @generate: none * @acl: domain:fs_freeze */ - REMOTE_PROC_DOMAIN_GET_FSINFO = 349 + REMOTE_PROC_DOMAIN_GET_FSINFO = 349, + + /** + * @generate: both + * @acl: domain:send_input + */
Just send_input? The result of the send is essentially 'init_control' right? Like a shutdown. Perhaps even like destroy (eg, 'stop'). Or 'shutdown'... I'm not sure of all the options here, but this seems much more invasive than just sending input because the result of the sent key is a bit more "final".
Since you are able to do the same thing with the virDomainSendKey API which has the same ACL class:
virsh send-key dom KEY_LEFTALT KEY_SYSRQ KEY_O
I don't think it should require any other permission since it's just a keystroke basically.
Agreed, 'send_input' basically gives away the keys to the kingdom, so there's nothing to gain by having a separate permission for this new API As a general rule we should always seek to reuse existing permissions because we don't want to end up having one permission for each separate API Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|