DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 407393858C83
Date: Thu, 20 Apr 2023 14:04:01 -0400
To: Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com
Subject: Re: posix_spawn facility
Message-ID: <ZEF+kVZZ/l6IWJqb@xps13>
References: <1752276.7aRn1RRit1@nimes> <ZEDmai2kO+dfxWut@xps13>
 <ZED5SOzW5QAkfxje@calimero.vinschen.de> <1853259.CQOukoFCf9@nimes>
 <ZEFKW/rbAS8x4QbV@calimero.vinschen.de>
 <ZEFO9ELNzIliSGPv@calimero.vinschen.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ZEFO9ELNzIliSGPv@calimero.vinschen.de>
Precedence: list
From: "gs-cygwin.com--- via Cygwin" <cygwin@cygwin.com>
Reply-To: gs-cygwin.com@gluelogic.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On Thu, Apr 20, 2023 at 04:40:52PM +0200, Corinna Vinschen via Cygwin wrote:
> On Apr 20 16:21, Corinna Vinschen via Cygwin wrote:
> > On Apr 20 12:18, Bruno Haible via Cygwin wrote:
> > >      The "inheritable handles" is a data structure that allows for the
> > >      arbitrary reshuffling of file descriptors required by posix_spawn
> > >      (the addopen, adddup2, addclose actions), i.e. which does the book-
> > >      keeping which HANDLE must in the end be open in the parent and which
> > >      must in the end be open in the child, and at which position.
> > 
> > Hmm.  Your code uses lpReserved2 for that, but the functionality is
> > one implemented in MSVCRT.  For obvious reasons, Cygwin executables
> > are not linked against msvcrt.dll and we're using lpReserved2 for our
> > own purposes.
> 
> Oh, btw., did you know that there's a newer mechanism for defining
> specific inheritable handles to CreateProcess, which is implemented
> in kernel32.dll, so it does not depend on MSVCRT?
> 
> There's a STARTUPINFOEX structure which allows to specify the 
> additional handles.  See
> 
> https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa
> 
> and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in
> 
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

An example using these to run CGI programs in lighttpd on Windows
using native _WIN32 code can be seen on my dev branch (intended for
lighttpd 1.4.70).

https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/personal/gstrauss/master/src/fdevent_win32.c#L539
(lighttpd is BSD-3-Clause)

The aim is to securely manage which handles are inherited by child CGI
processes.  Elsewhere, lighttpd clears HANDLE_FLAG_INHERIT on handles
lighttpd creates, and uses WSA_FLAG_NO_HANDLE_INHERIT in calls to
WSASocket() func family.  Also in that file, I have an (expensive)
socketpair() implementation, since lighttpd uses sockets instead of
pipes to connect to CGI programs, so that events can be received using
WSAPoll() or select().

To get things working in native _WIN32 lighttpd, which has a test
framework that runs under Cygwin, I had to detect and perform some path
translation between native Windows and Cygwin paths.  While my solution
is specific to lighttpd's use, I hope that this may give you some ideas.

Cheers, Glenn

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple