[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 5/8] Extend RPC protocol to allow FD passing



On 10/25/2011 06:26 AM, Daniel P. Berrange wrote:
On Mon, Oct 24, 2011 at 03:39:46PM -0600, Eric Blake wrote:
@@ -135,7 +152,11 @@ enum virNetMessageType {
      /* either direction. async notification */
      VIR_NET_MESSAGE = 2,
      /* either direction. stream data packet */
-    VIR_NET_STREAM = 3
+    VIR_NET_STREAM = 3,
+    /* client ->   server. args from a method call, with passed FDs */
+    VIR_NET_CALL_WITH_FDS = 4,
+    /* server ->   client. reply/error from a method call, with passed FDs */
+    VIR_NET_REPLY_WITH_FDS = 5

Have you tested the case where client sends 4 but server does not
understand it?  Likewise, what if server sends 5 but client does not
understand it?  Are those graceful failures?  Do we risk stranding a
leaked fd into the side that wasn't aware of how to handle the new
protocol?

IIUC, a remote application can send as many FDs as it likes.
Until you actually do recvmsg() to accept the FD handle, the
file handle does not exist in the process ?

OK, you're right that there is no fd leak. It is the recvmsg that tells the kernel to actually expose the fd into the client; if it were not so, then you could DoS an arbitrary process by sending it extra fds.

However, I'm still wondering if the receiving end gracefully handles the unknown message type. And since VIR_NET_CALL_WITH_FDS is normally synchronous and expects a reply, does that mean the client has to reply with an explicit error, or does it mean that the server has to tolerate the lack of a reply, or will we have deadlock? Or do we need some sort of capability handshake where the client probes whether the server supports CALL_WITH_FDS before using it?

--
Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]