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

Eric Blake eblake at redhat.com
Tue Oct 25 15:00:20 UTC 2011


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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org




More information about the libvir-list mailing list