>> On 12/12/2014 at 09:38 PM, in message
<20141212133825.GJ32050(a)redhat.com>,
"Daniel P. Berrange"
<berrange(a)redhat.com> wrote:
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(a)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
Got it. Thanks.