[Libvir] Remote patch, 2007/02/19

[Daniel P. Berrange]

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 ?

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|