On 03/28/2018 01:28 PM, Ross Lagerwall wrote: > On 03/27/2018 11:21 AM, George Dunlap wrote: >> On 03/26/2018 05:43 PM, Ian Jackson wrote: >>>> +### Network >>>> +If QEMU runs in its own network namespace, it can't open the tap >>>> +device itself because the interface won't be visible outside of its >>>> +own namespace. So instead, have the toolstack open the device and pass >>>> +it as an fd on the command-line: >>> >>> I think this could be solved by doing these things in a different >>> order. >> >> Ross, do you have a reference for the qemu-devel discussion where they >> rejected the patches to have QEMU restrict the namespaces? >> > > The thread starts here: > https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04674.html
Thanks. The key objection seems to be that things on the command-line will behave differently than subsequent commands sent over QMP. But of course, that's exactly the point. :-) And as you pointed out in that thread, it's no different than chroot. It is suboptimal to have QMP commands return 'success' when they don't actually have any effect; so a better interface would be to arrange that all QMP commands use an unshared namespace fail. That said, architecturally, doing as much of the restriction before exec'ing QEMU seems a lot cleaner to me. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
