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

Daniel P. Berrange berrange at redhat.com
Tue Oct 25 12:26:00 UTC 2011


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 ?

If that's correct, then the only leak scenario would be if an
old client did a recvmsg for the FD and then just discarded it,
which can't happen since old client never knew to do recvmsg.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list