RFC: adding fd-passing to win32

[Marc-André Lureau]

Hi there

On Mon, Jul 18, 2022 at 2:23 AM Thiago Macieira <thiago at kde.org> wrote:

> On Tuesday, 12 April 2022 04:15:56 PDT Marc-André Lureau wrote:
> > Any other idea? (of course, the protocol change would need to be
> negotiated
> > first!)
>
> Negotiating FD passing is already done on Unix in the preamble section of
> authentication done before D-Bus messages start being exchanged. So having
> to
> negotiate it on Windows would not be a new thing. Passing a slightly
> different
> structure would, but so long as it's done behind a negotiation it should
> be
> fine.
>
>
I have made some progress on this front, but could use some help or
feedback.

Similar to fd-pass, it's using a negotiation to determine whether the peers
have support and capabilities, and a new field to indicate the presence and
size of a "handle array" that is attached to a message. The array elements
have the handle type & value or details for SOCKET. The body 'H' arguments
index the array, similar to 'h' FDs values. The sender has to
DuplicateHandle/WSADuplicateSocket when sending the message and build that
"a{yv} handle array" (for each receiver). The receiver then imports back
the handles and substitute handle values.

With glib & zbus, I can simply append the array after the message, and
parse it back. The array size in bytes is easy to retrieve. It seems to
work fine.

But with dbus reference implementation, it's a bit more complicated and
makes me wonder about this design.

It seems the D-Bus protocol was designed so that the message size can be
computed from the header alone, with header + body + fields array size. The
reference implementation relies on that
(_dbus_header_have_message_untrusted for ex). The choice I made so far
imply that the message size depends on those + reading the WIN32_HANDLES
field & if set, read *after* the body the "handle array" size. This is a
bit tricky to handle in dbus reference implementation today, but if this is
the right option, I can probably make it work. But maybe I am missing
something in the original design, about message processing, locality etc

1) Would it be a better design to add a 3rd UINT32 to the message header,
to indicate the size of the handle array?

2) Or change the header body length to be message body + "handle array"
sizes. This would make importing handles a bit tricky, as you would need to
first parse the body to be able to know the offset of the handle array.

3) Add a new message type, with the "handle array" associated with the next
message.

That 3rd option is appealing, even if it has some overhead and extra
complications too.

For now, I will try to continue with the original design, see if I can
teach it to the dbus reference implementation. But I welcome any
suggestion, ideas etc

thanks!

-- 
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20220803/9c7a8f25/attachment.htm>