[Libvir] Remote patch, 2007/02/19

[Richard W.M. Jones]

Daniel P. Berrange wrote:
> 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.

I was hoping to avoid this.  Note that the contents of the sunrpc/ 
subdirectory (the client and server transports) are independent of 
libvirt and I hoped to publish them separately so they could be reused 
in other places.  The other problem is the Unix transport, where we use 
the transport from glibc directly.  Anyway, still thinking about this 
(the last few days have been a dead loss because of new laptop and 
wireless problems).

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

I'll take a look at this.

Rich.
-- 
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421
  "[Negative numbers] darken the very whole doctrines of the equations
  and make dark of the things which are in their nature excessively
  obvious and simple" (Francis Maseres FRS, mathematician, 1759)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070223/0bd242e8/attachment-0001.bin>