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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list