But how about selinux? I'm run qemu-ga in guest and want to modify the authorized_keys file of some user? Do we need to extend the selinux policy to allow modification of such files in all guests? чт, 12 нояб. 2020 г. в 19:41, Peter Krempa <pkrempa@redhat.com>:
On Thu, Nov 12, 2020 at 16:27:02 +0000, Daniel Berrange wrote:
On Thu, Nov 12, 2020 at 05:18:06PM +0100, Michal Privoznik wrote:
On 11/12/20 3:46 PM, Peter Krempa wrote:
Saying that virDomainQemuAgentCommand is fully supported to be used would free us from having to add arbitrary unextendable APIs for every single guest agent API, but would still allow libvirt to use APIs we need.
By saying that mgmt apps will need to learn json apart from xml. I'm not saying it's necessarily a bad thing - mgmt application is probably written in a language that already has a JSON library built in (golang, python).
You also loose the benefit of libvirt's API abstraction. If QEMU guest agent is replaced by something different in future, a formal API in libvirt insulates the apps from that difference, both within context of a single hypervisor, and cross hypervisor.
Yes, basically my question was whether it's worth doing individual APIs for all of those things especially since we usually don't try to deal with what's running inside the VM. I'm not 100% persuaded, but we have plenty prior art and the insulation argument makes sense (as long as the replacement has the capabilities).
If we do want to keep adding the APIs I'm fine with the patches as-is, as any other solution would be extremely gross.
Obviously v2 is required due to the security problems.
-- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru