Patch to pass file descriptors

[Conrad Scott]

"Corinna Vinschen" <cygwin-patches@cygwin.com> wrote:
> > 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) :-)
>
> You got it.  Therefore a thread is ok.  Calling another process is
> basically too much effort, IMO.

I suppose that was what I was working towards: we don't need to get
that hung up about some of the more remote possibilities, so possible
"solutions", like creating a new process, aren't worth considering
(for the non-cygserver implementation) since they aren't needed for
the common cases.

> Is POSIX compliance actually a problem at all?  I don't think so.
> SUSv3 doesn't mention descriptor passing in sendmsg/recvmsg at all.

Doh! Of course.

> What we're trying to do is some sort of BSD compatibility.

That's what I meant! Well, it's what I would have meant had I thought
about it a bit more :-)

> I don't
> even demand full compatibility (e. g. the Cygwin header still
defines
> the old style msghdr definition), I just want to pass descriptors
> for the most typical class of problems.  Sshd passes pseudo tty
> descriptors in the privsep code.  That, sockets, pipes and files
> are the most important ones.  Everything else can follow later.

Understood.

> One of the processes needs enough privileges to call a
> OpenProcess(PROCESS_DUP_HANDLE) on the other process.
> This can be
> figured out by just exchanging the Windows PIDs.  If this isn't
possible,
> we're stuck anyway and it would require the cygserver solution.

I've got to look at this whole issue of getting hold of process
handles to get a handle (pun! pun!) on the security issues in
cygserver. Exactly which privileges are required for what is still a
black art to me. Time for some more reading.

// Conrad