From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MObmL-0005vd-I0 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:22:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MObmG-0005tl-57 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:22:00 -0400 Received: from [199.232.76.173] (port=37038 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MObmF-0005tX-WD for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:21:56 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]:41303) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MObmF-00056a-K2 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:21:55 -0400 Received: by pzk15 with SMTP id 15so1513084pzk.4 for ; Wed, 08 Jul 2009 11:21:54 -0700 (PDT) Message-ID: <4A54E3BC.40306@codemonkey.ws> Date: Wed, 08 Jul 2009 13:21:48 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands References: <1247064963.3270.63.camel@blaa> <1247065048-15706-1-git-send-email-markmc@redhat.com> <1247065048-15706-2-git-send-email-markmc@redhat.com> <1247065048-15706-3-git-send-email-markmc@redhat.com> <4A54BABD.3040903@redhat.com> <1247069035.3270.82.camel@blaa> <4A54C634.30007@redhat.com> <4A54E0B3.8090305@codemonkey.ws> <4A54E160.9000900@redhat.com> In-Reply-To: <4A54E160.9000900@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , qemu-devel@nongnu.org Avi Kivity wrote: > On 07/08/2009 09:08 PM, Anthony Liguori wrote: >> Avi Kivity wrote: >>> I'd prefer the communication layer to queue fds and getfd to dequeue >>> them. >> >> How many do you queue? The correct answer is one, btw ;-) > > You queue as many as you receive, and you dequeue as many getfd > commands as you get. Then someone can connect to the monitor and consume an arbitrary number of fds? I'd be very concerned about the potential to leak fds within QEMU from a poorly written client. Seems like a very easy mistake to make. > Nothing prevents the client from sending two getfd commands in a > single packet. We can either support it or start writing detailed > documentation and handle the bug reports when people don't read it. What would a client do that would result in this happening? It's really a contrived example when you think about it pragmatically (at least given today's monitor). Regards, Anthony Liguori