[cap-talk] Socket transfer between Windows processes (was: NaCl descriptors are not (all) capabilities)

[David-Sarah Hopwood]

Mark Seaborn wrote:
> I have been digging into Native Client's socket descriptor types,
> which unfortunately are not documented at the moment.  It turns out
> that NaCl is not quite a capability system:  some types of descriptor
> can be sent in messages across sockets (using
> imc_sendmsg()/imc_recvmsg()), but some cannot.  Another way to say
> this is that some descriptor types are not first class.  Apparently
> the reason for this is that it is difficult to implement cross-process
> descriptor transfer on Windows.

Hmm. According to
<http://blog.henning.makholm.net/2008/06/unix-domain-socket-woes.html>:

# There's a dedicated system call, WSADuplicateSocket(), for exactly this
# scenario. This syscall fills in an opaque structure in the doorkeeper
# [sender] process, whose binary content you then transmit to the service
# [recipient] process (say, through pipes that you set up when the service
# process was started). In the service process another system recreates a
# copy of the socket for you, and then you're free to close the
# doorkeeper's socket handle.

I have not tried this, and I bet it's more complicated than that in
practice. However, looking at the API docs for WSADuplicateSocket
<http://msdn.microsoft.com/en-us/library/ms741565%28VS.85%29.aspx>
doesn't immediately turn up any showstoppers.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091125/3e8c6dca/attachment.bin