This is the mail archive of the
mailing list for the Cygwin project.
Re: Patch to pass file descriptors
"Corinna Vinschen" <email@example.com> wrote:
> > If that
> > covers most of the uses, a non-cygserver implementation will be
> > enough; the cygserver version is just to claim full Posix
> > (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
> 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.
> 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
> 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.