[cap-talk] Socket transfer between Windows processes

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> 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.

Ah, but that will only work between processes run by the same user:
<http://www.eggheadcafe.com/forumarchives/win32programmernetworks/Sep2005/post23674318.asp>
It's probably more complicated than that, but obviously there must be some
access control involved in that case, and it probably isn't what we want.

It seems that DuplicateHandle can be used to transfer handles with
capability-like semantics.
See <http://msdn.microsoft.com/en-us/magazine/bb985041.aspx>.

DuplicateHandle doesn't work on sockets, but something sufficiently like
local sockets could be implemented in terms of pipes (either named or
anonymous), and then the connected pipe endpoint handles would be
transferrable.

Mark Seaborn wrote:
> In NaCl, the filename string is replaced with a pair of descriptors,
> created by the system call imc_makeboundsock(), of types SocketAddress
> and BoundSocket.
[...]
> In NaCl, the primary means of sharing is to share SocketAddress
> descriptors, because ConnectedSockets are not transferrable.
>
> The reason ConnectedSockets are not transferable is that the current
> implementation of descriptor-passing on Windows requires that the
> recipient process does not change during an imc_sendmsg() operation.

Makes sense, if they implement NaCl sockets as Windows sockets. If they
reimplemented them as pipes, then I think it could be made to work. But
pipes are sufficiently different to sockets that this would likely involve
a lot of rework (to the implementation of NaCl sockets, not necessarily
its interface).

-- 
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/20091126/4a821b4c/attachment.bin