From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44816 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PS3mu-0002Go-Cf for qemu-devel@nongnu.org; Mon, 13 Dec 2010 03:29:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PS3mr-0006Rx-Qv for qemu-devel@nongnu.org; Mon, 13 Dec 2010 03:29:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PS3mr-0006Rl-Im for qemu-devel@nongnu.org; Mon, 13 Dec 2010 03:29:37 -0500 Message-ID: <4D05D967.4060500@redhat.com> Date: Mon, 13 Dec 2010 09:29:27 +0100 From: Jes Sorensen MIME-Version: 1.0 References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <1291399402-20366-9-git-send-email-mdroth@linux.vnet.ibm.com> <4CFE4406.4010209@redhat.com> <4D01465B.9040200@linux.vnet.ibm.com> <4D01CC2D.10706@redhat.com> <4D025EDC.1040600@linux.vnet.ibm.com> In-Reply-To: <4D025EDC.1040600@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v5 08/21] virtagent: add agent_viewfile qmp/hmp command List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com On 12/10/10 18:09, Michael Roth wrote: > I think with strictly enforced size limits the major liability for > viewfile is, as you mentioned, users using it to view binary data or > carefully crafted files that can mess up or fool users/shells/programs > interpreting monitor output. > > But plain-text does not include escape sequences, so it's completely > reasonable that we'd scrape them. And I'm not sure if a "(qemu)" in the > text is a potential liability. Would there be any other issues to consider? > > If we can guard against those things, do you agree it wouldn't be an > inherently dangerous interface? State-full, asynchronous RPCs like > copyfile and exec are not really something I'd planned for the initial > release. I think they'll take some time to get right, and a simple > low-risk interface to cover what I'm fairly sure is the most common use > case seems reasonable. I am still wary of relying on strict limit enforcement. It is the sort of thing that will eventually change without us noticing and we end up with a security hole. IMHO QEMU should not try to do these sorts of things, instead it should provide the transport and control services. I don't think file viewing belongs in QEMU at all. I would be a lot more comfortable if this was implemented as a standalone monitor interface that connected to QEMU's QMP interface. I could then use QMP to perform actions like copying the file to /tmp and if viewing the file caused the monitor to lock up, we wouldn't lose the guest. This could indeed be the start of an external monitor :) Cheers, Jes