RFC: adding fd-passing to win32

[Simon McVittie]

On Thu, 25 Aug 2022 at 21:24:24 +1200, Lawrence D'Oliveiro wrote:
> OK, on further examination, seems that is part of the STREAMS module,
> which is not commonly supported these days. But according to this
> <https://gist.github.com/kentonv/bc7592af98c68ba2738f4436920868dc>, the
> BSDs do support SCM_RIGHTS for FD-passing, as does Linux. So that
> covers all the nonproprietary POSIX-conforming OSes, as far as I’m
> aware.

Implementation experience from libdbus and GDBus is that "most" Unixes
support this in some form, but the devil is in the detail: for example
libdbus' implementation of fd-passing compiles on FreeBSD and works in
simple cases, but there are unfixed unit test failures. Meanwhile
the equivalent on Solaris always sort-of-worked, but until 2020 it would
crash with a buffer overflow if the out-of-band message got truncated.

The situation is less bad for SCM_RIGHTS than for credentials-passing,
which seems to be supported in some form on most Unix OSs, but different
on each one, such that we need approximately one code path per OS.

For many portability issues, if the code we tested on Linux/x86 compiles
successfully on another OS or CPU, we can be somewhat confident that it
will work on the other OS or CPU, but fd-passing does not seem to be one
of those: it's the sort of thing that we can only be confident about on a
particular platform if someone has literally tested it on that platform,
and preferably is continuing to test regularly on that platform. In
general, non-type-safe interfaces like ioctl(), fcntl(), getsockopt()
and ancillary messages, where you need to know the correct interpretation
of a particular parameter from documentation, seem to have a higher
risk of compiling but then not working than type-safe interfaces (which
makes sense, the compiler is unable to alert us to having made the wrong
assumptions about a non-type-safe interface for a particular platform).

    smcv