[libvirt] [RFC] Design executing commands from within domains

[Chen Hanxiao]

At 2016-08-08 23:19:26, "Daniel P. Berrange" <berrange at redhat.com> wrote:
>On Mon, Aug 08, 2016 at 05:00:38PM +0200, Michal Privoznik wrote:
>> Dear list,
>> 
>> while wiring qemu-ga into libvirt I've noticed that it has ability to
>> spawn commands inside guest. I haven't paid much attention to it then as
>> implementing libvirt <-> qemu-ga communication was more important. But
>> lately couple of requests on the list showed up where ability to spawn
>> various commands inside guests would be much appreciated (e.g. when
>> fetching some stats that HV can't know or has no support for yet -
>> free/df/..).
>> 
>
>I never really liked the qemu guest agent ability to run arbitrary commands.
>It is basically re-inventing the shell but with really awful features. eg the
>having to provide all the input  upfront, not having any  way to stream large
>stdout/stderr data back to the host.
>
>Further, from a security POV it is really bad practice to have this feature
>in QEMU guest agent, as it makes it impossible to provide any kind of sane
>security confinment for the GA. IIRC, default Fedora SELinux policy will not
>even permit the exec command to be to used. Most of the QEMU GA commands have
>very tight scope so are easily confined, but 'exec' by its very nature wants
>todo anything. From that POV, a general purpose exec facility is really better
>suited to a separate command.

Users could ban it inside VM by blacklist.
Also, with default SELinux policy, qga could not do anything more.
So it's under control.

>
>Also from an API modelling POV, exposing the guest agent exec in libvirt
>is pretty much giving up on any sense of API design. It'll just discourage
>anyone from ever writing any further special case guest agent commands
>with formal APIs.
>
>IOW, I don't think we should ever expose the qemu guest agent exec command
>via libvirt APIs.

We've had qemuAgentCommand.
So I think it's better for a new public API.

Regards,
- Chen