This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)

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

>  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
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:
Sent from the Cygwin list mailing list archive at

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]