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

At 2016-08-08 23:19:26, "Daniel P. Berrange" <berrange(a)redhat.com&gt; 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.