Re: [Xen-devel] [PATCH v2 1/6] docs/qemu-deprivilege: Revise and update with status and future plans

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Fri, Sep 28, 2018 at 12:37:22PM +0100, George Dunlap wrote:
> On Tue, Sep 25, 2018 at 12:20 PM Anthony PERARD
> <anthony.perard@xxxxxxxxxx> wrote:
> >
> > On Fri, Sep 21, 2018 at 06:04:23PM +0100, George Dunlap wrote:
> > > +## Migration
> > > +
> > > +When calling xen-save-devices-state, since QEMU is running in a chroot
> > > +it is not useful to pass a filename (it doesn't even have write access
> > > +inside the chroot). Instead, give it an open fd using the add-fd
> > > +mechanism.
> >
> > That describe an issue only on save. The restore part of a migration
> > also have an issue:
> >
> > On restore, QEMU signal to libxl that it is ready only after priviledge
> > restriction have been put in place (and after or when it receive the
> > migration data). But xenstore isn't available anymore, so restore fails
> > from libxl point-of-view.
> >
> >
> > Or maybe you describe here an issue that would arise when an hypothetic
> > chroot is apply. But the migration issue describe here still apply
> > without chroot and with only -runas, the path libxl give to QEMU is
> > accessible by root only.
> 
> Do our other restrictions -- chroot, deprivilege, &c -- all work on
> restore at the moment?

chroot isn't an issue for restore. But running QEMU as non-root user is
currently an issue for restore.

I think the only issue with restore that doesn't also exist when
creating a guest is restricted access to xenstore.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel