Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <00a401c26e49$15ab21c0$1e02a8c0@VXMLDEV> From: "Marius Seritan" To: Subject: Problem with Station/Desktop permissions Date: Mon, 7 Oct 2002 14:32:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id g97LUOc24674 /description of the problem/ I am writing a win32 service for Windows NT4sp6a. On the same machine I am running sshd in a cygwin environment, with ntsec turned on. My win32 service does not use any of the cygwin services/code. Unfortunately after I log in to an ssh window my service can no longer run its sub-processes. Also restarting the service breaks the ssh session, I get errors similar to the following -------- $ ls 1506 [main] -bash 206 sync_with_child: child 248(0x158) died before initialization with status code 0x80 2344 [main] -bash 206 sync_with_child: *** child state waiting for longjmp -bash: fork: Resource temporarily unavailable ----------- /Implementation details/ My win32 service needs to executes other exes either as the SYSTEM user or as another local user with less privileges. To avoid getting the nasty 'user32.dll cannot initialize' errors, I am following the guidelines from the Microsoft site on how to setup the permissions for the windows station/desktop: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q165194. I have some working code that allows my processes to share the default non-interactive desktop. From what I see from the sources, cygwin is also adjusting the permissions on the station\desktop. The approach taken in spawn.cc is a lot more radical though, the security descriptor is basically blown away. This seems to break my code. Has anybody else encountered this problem? Are there plans to move to a more nuanced approach when adjusting the permissions on the window stations/desktop? Thanks for any pointers/comments. Marius Seritan Engineering mseritan AT jacent DOT com