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