RFC: adding fd-passing to win32

[Marc-André Lureau]

Hi

On Tue, Aug 9, 2022 at 7:15 PM Thiago Macieira <thiago at kde.org> wrote:

> On Tuesday, 9 August 2022 00:51:38 PDT Marc-André Lureau wrote:
> > 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.
>
> You may want to think about widest compatibility too. I don't expect that
> afunix.sys will be as widespread, so implementing something that is able
> to
> work without it makes sense.
>

Honestly, I think it's sufficiently hard to do secure HANDLE passing than
trying to do it over TCP would be a mistake. And do we really consider
D-Bus over TCP secure anyway on Windows? I have doubts, because the way we
look up the peer process credentials is quite hackish.


> Compatibility with cygwin applications may not be your goal.
>
>
Why not?


> > My point is that 'h' is the right type to transfer FDs, not
> HANDLEs/SOCKET
> > etc.
>
> And you're still missing my point.
>
> The backend implementation is irrelevant. The fact that you get a file
> descriptor in the API is the important bit, and if on Windows you transfer
> a
> HANDLE but the API needs to do _open_osfhandle to return something to the
> user, so be it.
>
> Unless you tell us that you *can't* do that for SOCKETs, even if just as a
> holder so one can do _get_osfhandle later and get the HANDLE back.
>
>
We should avoid that mapping dance for native Windows HANDLE/SOCKETs. FDs
are often not helping on Windows, they often create extra issues (like
_close vs closesocket I mentioned).


> > > 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.
>
> Indeed, but those would be minor and focused. Not affecting the type
> system.
>
> > Frankly, adding 'H' is minor compared to the rest of the changes
> involved.
>
> No, it isn't.
>

Are we talking about the same thing? I did update the spec and I am working
on 3 different implementations, I deserve more credits.


> > Regarding compatibility, the 'H' type won't be used unless capability is
> > negotiated.
>
> But it'll exist.
>

Well, how did we introduce 'h' in the first place? It didn't exist before
0.13 or something. Was that so problematic, can you point me to related
issues?


>
> > 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.
>
> Thank you for more details.
>
> But this tells me that the API would need to split between HANDLE and
> SOCKET,
> so wouldn't you need two types instead?
>

Yes, as you can see from the example above, we need type information for
the "generic" HANDLE and SOCKET. I am handling that in the "handle array" I
talked about earlier.

I understand the desire to use 'h' FDs only, and in fact I started this way
in the gdbus implementation. But I have been convinced that the Windows API
need its own type to correctly deal with HANDLE vs SOCKET (or other more
marginals, and a bit less problematic such as Change Notification handle,
Event log handle, Find File handle, Update Resource handle, etc which must
also be closed with specific functions and whose type may not be easily
retrieved from FDs mapping).

Win32 FD mapping story is not a panacea, it looks full of pitfalls and
obscure cases. I think we should reserve it for the day AF_UNIX has
SCM_RIGHT with FDs support, and use the same code on Unix & Windows for it.

In the meantime, introduce the 'H' type for Windows native handles, and
provide native and safe handle APIs (not doing the FD mapping).

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