Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)

[Tor Lillqvist <tml iki fi>]

> btw: I don't know if passing HANDLE on Windows is supported (and I would
> guess not).

Sure it is. DuplicateHandle() can be used for this. I.e. a process A
that has the required access right (PROCESS_DUP_HANDLE) to two
processes U and V can take a HANDLE value valid in source process U
and duplicate it into a HANDLE value valid in the target process V.
Then it just needs to pass that new HANDLE value (which is just a
number, does not have to be kept secret or anything) using whatever
normal inter-process messaging to process V and process V can use it.

If I understand the documentation correctly,  A must be either U or V,
and in most cases presumably A == U, i.e. a process wants to give
another process a duplicate of one of its own HANDLEs.

Note that the duplicated handle is indeed just a number so no special
mechanisms are needed to pass it to the target process. In process A,
the duplicated HANDLE is not valid. It might have the same numeric
value as some HANDLE (that refers to a totally unrelated object) in
process A, but that is just a coincidence then.

I hate to say this, but IMHO this a more obvious API than the fd
passing over socket thing, which I have always found inelegant,
non-obvious, and in a way quite non-Unixish.

But then, ha, having said that, I now see this gem in the documentation:

"You should not use DuplicateHandle to duplicate handles to the
following objects: [,,,] Sockets. No error is returned, but the
duplicate handle may not be recognized by Winsock at the target
process. Also, using DuplicateHandle interferes with internal
reference counting on the underlying object. To duplicate a socket
handle, use the WSADuplicateSocket function."

OK, so for sockets one needs to call WSADuplicateSocket() instead of
DuplicateHandle(), and WSADuplicateSocket() takes just a target
process parameter. Oh well, that corresponds to the most common case A
== U anyway.

(Windows named pipes also have functionality that I think could be
used in a vague sense to achieve the same end means that fd passing is
often used for, i.e. give another process access to something (an
opened file) it wouldn't have access to (be able to open) otherwise. I
am talking about the "impersonation" thing, but actually now that I
think of it, this functionality is presumably usually used not to give
the named pipe server access to something it wouldn't have access to
otherwise, but on the contrary, to make a named pipe server restrict
its rights to those of the client. And anyway, as Thiago has pointed
out on the dbus list, named pipes are a pain to use.)

--tml