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 ?
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 -=|