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@xxxxxxxxxx>: > > 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@xxxxxxxxx
