[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