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