Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

From: George Dunlap <george.dunlap@citrix.com>
To: Ross Lagerwall <ross.lagerwall@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
Date: Wed, 28 Mar 2018 14:26:48 +0100	[thread overview]
Message-ID: <bc8ab22b-2892-abd8-28a6-070e6a7cfb7d@citrix.com> (raw)
In-Reply-To: <620d8295-c6de-7b32-9ef3-597c99f8b1eb@citrix.com>

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