Patch to pass file descriptors

[Conrad Scott]

"Robert Collins" <robert.collins@syncretize.net> wrote:
> "Corinna Vinschen" <cygwin-patches@cygwin.com> wrote:
> > A change in the concept would eliminate that.  The sender process
> > could start a thread and duplicate all file handlers/HANDLEs.  So
> > the main thread in the sender isn't blocked.  The receiver is
blocked
> > anyway since it has to wait until all file handle information has
> > been correctly transmitted/regenerated.
>
> This is still incomplete, the parent now cannot exit(). I think that
it is a
> reasonable fall-back position for when the cygserver isn't running
though.

If this is a problem, the sender could always create a new process to
hold the handles until the receiver collected them. That sounds a bit
too heavy just to send a file descriptor but I don't expect that it
would done often enough to be unacceptable.

I suppose the issue here is not one of full Posix compliance (as none
of the discussion so far has approached that: e.g. how about sending
the file descriptor of a process's entry in the /proc fs?) but of what
needs to be done to cover enough cases to be useful. Corinna mentioned
that she'd want to use this in sshd (as I understood it): what's the
requirement there? Presumably the daemon's not about to exit and it's
only sending socket file descriptors? (all just guesses). If that
covers most of the uses, a non-cygserver implementation will be good
enough; the cygserver version is just to claim full Posix compliance
(one day) :-)

I lost track in the discussion of why shared memory was needed to pass
information between sender and receiver: why can't the sender just
send the data directly via the socket rather than putting it in shared
memory? The only reason I can see is to get around security issues in
duplicating the handles (i.e. the receiver sending its pid back to the
sender if it can't duplicate them). But the idea of the sender
duplicating its process handle with the relevant permissions would get
around that (?). The information passed could also include (the name
of?) a mutex that (a thread in) the sender waits on to know when it
can close the handles. Or am I missing something?

// Conrad