X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 358603857036 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1683710173; bh=JxCZGEtiEkGNvtMSfIkBnQk12uETLxyl5/TU4B6ohHY=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=v5yxyYb2WP/q72AZkND66N93gAQOgUvhzjsbfdKwxj//w6Ownsd9o9sJ8tZy0bgmI a/XluleqTTGax62JUjzFSLJtpKKgXVHCxkAdwwbTrCyhxQxpWO123/s3PFZWbinKOw NzCXhAnpCuwbAS0YXqMm0RkhxYZ0XBbBozFCuqJM= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C3E013858C31 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Language: en X-Spam-Relay-Country: X-Spam-DCC: B=; R=smtp1.atof.net 1102; Body=1 Fuz1=1 Fuz2=1 X-Spam-RBL: X-Spam-PYZOR: Reported 0 times. Date: Wed, 10 May 2023 05:15:25 -0400 To: cygwin AT cygwin DOT com Cc: Bruno Haible Subject: Re: posix_spawn facility Message-ID: References: <1752276 DOT 7aRn1RRit1 AT nimes> <4892432 DOT 0VBMTVartN AT nimes> <2162092 DOT C4sosBPzcN AT nimes> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "gs-cygwin.com--- via Cygwin" Reply-To: gs-cygwin DOT com AT gluelogic DOT com Content-Type: text/plain; charset="iso-8859-1" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 34A9Ga0T004328 On Thu, Apr 20, 2023 at 04:00:15PM -0400, gs-cygwin DOT com AT gluelogic DOT com wrote: > On Thu, Apr 20, 2023 at 09:31:38PM +0200, Bruno Haible wrote: > > Glenn wrote: > > > > > 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 > > > > ... > > > Excellent (very technical) article on the subject: > > > > > > Programmatically controlling which handles are inherited by new processes in Win32 > > > https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 > > > > It's nice to see an example for PROC_THREAD_ATTRIBUTE_HANDLE_LIST. > > > > But the article exaggerates a problem: > > "But all this inheritability fiddling still had a fatal flaw: What > > if two threads within the same process both call Create­Process but > > disagree on which handles they want to be inherited?" > > The answer, overlooked in the article, is to use DuplicateHandle > > and set the inheritability of the duplicate to true. Concurrently > > running posix_spawn invocations in other threads will not see the > > duplicates, since they only see HANDLEs that are assigned to file > > descriptors, not HANDLEs that merely reside in some data structure > > in memory. > > It might not be an issue if everything -- and I mean everything -- goes > through posix_spawn() to create processes. > > The article is from 2011 and about Windows. If a third-party dll > running in another thread calls CreateProcess() and does not explicitly > restrict the inherited handles using the techiques in the article, then > there is still that race that might leak additional handles into the > other process. > > In the case of cygwin, the cygwin layer could/should be able to > centralize and control process creation, avoiding the race. > Even if there were any steps that need to be protected, wrapping > in a CriticalSection (or mutex) would probably be sufficient. > > Cheers, Glenn lighttpd 1.4.70 includes support for native _WIN32 (separate build from cygwin) and includes a working (but slow) _WIN32 socketpair() as well as fully-functional code using CreateProcess() with the above techniques to limit filehandles inherited by CGI processes to only the stdhandles for stdin, stdout, and stderr. lighttpd 1.4.70 uses sockets (via socketpair()) instead of pipes for CGI on Windows since select() and WSAPoll() work only on sockets. Corinna: With the somewhat recent update to minimum Windows version supported by cygwin, I believe that using PROC_THREAD_ATTRIBUTE_HANDLE_LIST should be available on all cygwin-supported versions of Windows. Cheers, Glenn P.S. if any Windows developers look at the (BSD-3-Clause) lighttpd code and notice that I am doing something wrong or suboptimal on _WIN32, please do let me know how it can be improved. Thanks! -- 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