X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=4.0 required=5.0 tests=AWL,BAYES_00,BOTNET,FB_WORD1_END_DOLLAR,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Message-id: <005101ca001b$9587c360$8e0410ac@wirelessworld.airvananet.com> From: "Pierre A. Humblet" To: "Rajiv Garg" , References: <24395640 DOT post AT talk DOT nabble DOT com> <002301ca000f$242cb6a0$8e0410ac AT wirelessworld DOT airvananet DOT com> <786453 DOT 44646 DOT qm AT web1111 DOT biz DOT mail DOT sk1 DOT yahoo DOT com> Subject: Re: Intermittent Cron Errors Date: Wed, 08 Jul 2009 18:29:39 -0400 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 ----- Original Message ----- From: "Rajiv Garg" To: "Pierre A. Humblet" Sent: Wednesday, July 08, 2009 5:47 PM Subject: Re: Intermittent Cron Errors | | Pierre, | | Thanks for your reply. | | Yes, both the job and service are running under the same account (orderworker). I was looking into this a bit more, and found that we are getting the following event in our security event log at the exact time of the cron "can't switch user context" error. | | Event Type: Failure Audit | Event Source: Security | Event Category: Privilege Use | Event ID: 577 | Date: 7/8/2009 | Time: 4:30:17 PM | User: \orderworker | Computer: OMS1 | Description: | Privileged Service Called: | Server: NT Local Security Authority / Authentication Service | Service: LsaRegisterLogonProcess() | Primary User Name: OMS1$ | Primary Domain: | Primary Logon ID: (0x0,0x3E7) | Client User Name: orderworker | Client Domain: | Client Logon ID: (0x0,0xF1C649B8) | Privileges: SeTcbPrivilege | | This seems to confirm that it's an sporadic authentication issue between our server and our domain controllers, not cron or cygwin-related. I'm going to try to track this issue down and failing that, may try building a special version of cron to bypass setuid per your suggestion. I should be able to handle that, but if I have trouble, I may drop you a line. *************** Rajiv, Good investigation but I am not sure how you arrive at the conclusion. I can reproduce the same audit failure by attempting to setuid to another user without being privileged. strace shows the following: 50 336755 [main] a 536 set_privilege: -1 = set_privilege ((token 6F4) SeTcbPrivilege, 1) 930 337685 [main] a 536 subauth: LsaRegisterLogonProcess: -1073741759 which matches what your security log shows. So it looks like in your case cygwin does not recognize that the setuid should be a noop and tries to get a new security token. That behavior is flagged by the security audit. The attempt to get a new token may be due to a problem obtaining the groups of the user from the PDC, in an earlier call to initgroups. Unfortunately cron does not check the return value of that call. If you can do it easily, there is some value in running the test program I sent you. Pierre -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple