Re: [Libvir] Remote patch, 2007/02/19

On Wed, Feb 21, 2007 at 06:13:40PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >> With that in mind I'd venture to suggest we ditch the whole idea of cookies >> completely. >> >> Every method on the server end is already given a >> >> 'struct svc_req *req' >> >> This struct contains a field >> >> ' SVCXPRT *rq_xprt;' >> >> Which represents the data transport of the client. And the SVCXPRT struct >> has as its first member the ' int xp_sock' which is the socket associated >> with the client. >> >> So we can trivially & securely map from a client's TCP connetion to the >> virConnectPtr without needing any magic cookies. > What concerns me here is that xp_sock is just a file descriptor and fds > can be reused. It is also an fd that could be any of: > * a TCPv6 socket > * a TCPv4 socket > * a Unix domain socket > * on the client side, a socketpair (which on Linux is a funny type of > Unix domain socket) > So finding something unique about it may be tricky. What happens if two > clients connect in succession over the local Unix domain socket? I've just noticed that since we are providing our own server side transport implementations in sunrpc/svc_{tcp,ext,gnutls}.c we already have a place where we can safely put in cleanup hooks. In the 'svctcp_destroy' just after we call 'xprt_unregister' we can call out to purge client state associated with that FD. This ensures that we cleanup state before any new connection can re-use the same FD number. So there's actually no need to replace the svc_run() method in this case after all.

> Also worth noting is that cookies may represent other server-side > objects, in particular domains and networks. We can have multiple > domains per connection. The relationship between networks and > connections is complicated (and I don't pretend to understand it at the > moment either). I will be thinking about this too ... For domains & networks I imagine we'd just be passing a UUID / Name / ID across the wire to identify the object in question, as we do with the existing libvirt_proxy / qemu daemon ?