X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <26366622.post@talk.nabble.com>
Date: Sun, 15 Nov 2009 20:02:10 -0800 (PST)
From: aputerguy <nabble AT kosowsky DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: subinacl not consistent with getfacl under ssh login  (USERNAME=SYSTEM)
In-Reply-To: <26355883.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <26355883 DOT post AT talk DOT nabble DOT com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com


OK - I just re-read the ntsec portion of the cygwin manual and found this
paragraph:

>  This has the following unfortunate consequence. Consider a service
> started under the SYSTEM 
> account (up to Windows XP) switches the user context to DOMAIN\my_user
> using a token created 
> directly by calling the NtCreateToken function. A process running under
> this new access token might 
> want to know under which user account it's running. The corresponding SID
> is returned correctly, for
> instance S-1-5-21-1234-5678-9012-77777. However, if the same process asks
> the OS for the user 
> name of this SID something wierd happens. For instance, the
> LookupAccountSid function will not return
> "DOMAIN\my_user", but "NT AUTHORITY\SYSTEM" as the user name.

> You might ask "So what?" After all, this only looks bad, but functionality
> and permission-wise everything 
>should be ok. And Cygwin knows about this shortcoming so it will return the
correct Cygwin username 
> when asked. Unfortunately this is more complicated. Some native,
> non-Cygwin Windows applications 
> will misbehave badly in this situation. A well-known example are certain
> versions of Visual-C++.

So is 'subinacl' just another example of these badly behaved non-Cygwin
applications?
If so, is there anything one can do other than to use one of the other
methods to get a properly authenticated ssh login?


-- 
View this message in context: http://old.nabble.com/subinacl-not-consistent-with-getfacl-under-ssh-login-%28USERNAME%3DSYSTEM%29-tp26355883p26366622.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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