Re: [libvirt] [PATCH 5/8] Extend RPC protocol to allow FD passing
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org