Re: [libvirt] libguestfs integration: rich disk access for libvirt applications

On Wed, Sep 28, 2011 at 06:37:17PM +0100, Daniel P. Berrange wrote: > On Wed, Sep 28, 2011 at 11:14:57AM +0100, Stefan Hajnoczi wrote: > > On Tue, Sep 27, 2011 at 12:55 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: > > > To put this all into one place: > > > > > > (1) An ugly new libvirt API that runs febootstrap-supermin-helper to > > > create the appliance. > > [...] > > > I'm worried about item (1) in this list ... > > > > This is the only instance where libvirt knows about libguestfs. All > > other steps are libguest only or involve libguestfs knowing about > > libvirt. > > > > Would it be possible introduce a "domain-builder" concept into > > libvirt? When libguestfs is installed it drops a domain-builder > > configuration/script that libvirt can pick up. Then you can say > > something like virDomainBuild(name="guestfs-appliance", > > builder="guestfs"). > > We do have a historical syntax from Xen paravirt which lets us call out > to a helper at boot time, namely the "<bootloader>" element. With Xen > this is typically something like pygrub, or pxegrub, which does some > work and writes out a kernel+initrd into temporary files, and prints > the file paths + any kernel args on stdout. > > We could just wire up this concept in KVM too without any real trouble, > and then we could have guestfs-bootloader script todo the magic setup I'm fine with this. Are there security implications to allowing users to add <bootloader> clauses pointing at random scripts that get run on remote machines as different users?