[libvirt] [PATCH 6/8] Add client side support for FD passing

Daniel P. Berrange berrange at redhat.com
Tue Oct 25 12:28:11 UTC 2011


On Mon, Oct 24, 2011 at 04:23:16PM -0600, Eric Blake wrote:
> On 10/21/2011 06:55 AM, Daniel P. Berrange wrote:
> >@@ -697,6 +708,15 @@ virNetClientCallDispatch(virNetClientPtr client)
> >      case VIR_NET_REPLY: /* Normal RPC replies */
> >          return virNetClientCallDispatchReply(client);
> >
> >+    case VIR_NET_REPLY_WITH_FDS: /* Normal RPC replies with FDs */
> >+        if (virNetMessageDecodeNumFDs(&client->msg)<  0)
> >+            return -1;
> >+        for (i = 0 ; i<  client->msg.nfds ; i++) {
> >+            if ((client->msg.fds[i] = virNetSocketRecvFD(client->sock))<  0)
> 
> You do realize that gnulib's sendfd/recvfd pass a single byte
> alongside each out-of-band fd (since passing fds with 0-byte
> messages isn't portable).  It looks like you were careful to ensure
> that fds are only sent and received in between complete messages; so
> hopefully we don't ever run into any problems where the extra byte
> payloads gets interleaved with real rpc traffic, since that could
> cause confusion on the current state of bytes going between
> endpoints.  Is encryption ever used on UNIX sockets, or is that only
> for TCP connections?

In theory you can run SASL over the UNIX socket which could layer
in encryption, but IIRC we always disable the encryption layer
with SASL.

It is kind of annoying that sendfd/recvfd actually put real
data into the stream. This can certainly muck up this code,
since I would need to be careful to always make sure to
put the sendfd/recvfd calls in the right place wrt sending
or recving the payload. My testing suggests I have this right,
but will need to double check now for sanity

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