RFC: adding fd-passing to win32

[Marc-André Lureau]

Hi Thiago

On Mon, Aug 8, 2022 at 8:19 PM Thiago Macieira <thiago at kde.org> wrote:

> On Monday, 8 August 2022 04:40:22 PDT Marc-André Lureau wrote:
> > FDs are not HANDLEs, we shouldn't mix the two (a mistake commonly
> observed
> > and annoying to clean up).
>
> I never claimed otherwise. My point is that the wire format is an
> implementation detail.
>
> > If some day Windows sockets learn SCM_RIGHT, we should transfer FDs
> values.
>
> Highly doubtful. It's doubtful that it'll learn that Linux-specific
> feature and
> it's doubtful that file descriptor values will be transferable. They
> aren't on
> Linux anyway: the file descriptor value is not retained. You get a new
> file
> descriptor locally, which happens to map to the same kernel-side structure.
>
>
If we are able to find solutions at D-Bus level, it's not impossible they
implement better low-level solutions in afunix.sys. See also cygwin
discussion pointed by Lawrence.


> > We could eventually use 'h' for FDs or HANDLEs or SOCKETs (or other kind
> as
> > necessary), the "handle array" contains the type details. But then 'h'
> > implementation will be different on Windows, regardless of potentially
> > future same SCM_RIGHT support. I think it's a better idea to treat
> HANDLEs
> > as a different type.
>
> I disagree.
>
> Let's make this easier for you:
>
> If you use 'h' and just make the reference implementation work, then all
> the
> implementations that use it will automatically gain the functionality.
> You'll
> only need to do code reviews, without a spec change, with most of the
> changes
> restricted to win32-specific files. You'll need to update the
> implementations
> that do D-Bus socket directly, but similarly they will not have any user
> API
> change and applications should work unmodified.
>

My point is that 'h' is the right type to transfer FDs, not HANDLEs/SOCKET
etc.


>
> If you use 'H', you'll first need to start with a spec update and you'll
> need
> to convince people like Simon and myself, who don't have as extensive
> Windows
> knowledge, that it is needed (and this thread is pointing that we aren't
> getting convinced). You'll need code reviews throughout the implementation
> to
>

Spec update will be needed for nego phase, details of HANDLE transfer etc.
Reference implementation changes are required anyway.

Frankly, adding 'H' is minor compared to the rest of the changes involved.


> support a new type. Then you'll need to update the API in libdbus-1, then
> all
> the implementations that use it, including fixing them where they expect
> to
> know the full population of D-Bus types but now don't. That is a much
> tougher
> ask.
>

Well, I have working PoCs for gdbus & zbus already. Only libdbus is a bit
more difficult to deal with.

Regarding compatibility, the 'H' type won't be used unless capability is
negotiated.


>
> Maybe your objective has never been to retain source compatibility across
> platforms. But then please explain why that is not a goal.
>

It would be great if we could reuse our existing interfaces using 'h', with
SCM_RIGHT or not. Unfortunately, that's not the case. You need
HANDLEs/SOCKETs to be able to call DuplicateHandle or WSADuplicateSocket or
close appropriately. We can try to make guesses on the underlying objects
(by mapping FD->HANDLE->SOCKET for ex), but that would be a bit fragile and
not necessarily the most convenient API to use for the client on win32:

SOCKET s = WSASocket(..)
int fd = _open_osfhandle(s,..)
dbus_message_append_args(.., DBUS_TYPE_UNIX_FD, &fd,..)

In libdbus, or receiver
dbus_message_get_args(.., DBUS_TYPE_UNIX_FD, &fd)
HANDLE h = _get_osfhandle(fd)
if (is_socket(h)) /* see
https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gwin32.c#L1457 for ex
*/
{
  SOCKET s = (SOCKET)h;
  ..
  WSADuplicateSocket(s, ) to target process for ex..
  ..
  closesocket(s) /* in theory better than _close(), but this also unclear!
*/
} else {
  DuplicateHandle(h, )..
  _close(fd)
}

If we expose HANDLE & SOCKETs directly instead (both in APIs and protocol),
we don't need to juggle with the fd back/forth mapping and potential
guesses & pitfalls.

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