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(a)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(a)selfip.ru