Re: SMBFS mount's file cannot be made executable

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Nov 12 17:54, Takashi Yano via Cygwin wrote:
> I noticed that the probelm is not only in samba share, but
> also in Windows share.
> 
> Yesterday, I used shared resource of the root directory.
> In that case, access right of Authenticated Users was enabled.
> However, when I tried resource under the user folder, the access
> right of Authenticated Users is not assigned as follows.
> 
> $ icacls '\\kappy3\Share\smb_shared_file.txt'
> \\kappy3\Share\smb_shared_file.txt NULL SID:(DENY)(Rc,S,X,DC)
>                                    S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO)
>                                    NT AUTHORITY\SYSTEM:(DENY)(S,X)
>                                    BUILTIN\Administrators:(DENY)(S,X)
>                                    S-1-5-21-2089672436-4097686843-2104605006-513:(R)
>                                    NT AUTHORITY\SYSTEM:(RX,W)
>                                    BUILTIN\Administrators:(RX,W)
>                                    Everyone:(R)
> 
> Successfully processed 1 files; Failed processing 0 files
> 
> $ ls -l //kappy3/Share/smb_shared_file.txt
> -rw-r--r--+ 1 Unknown+User Unknown+Group 0 11月 12 15:50 //kappy3/Share/smb_shared_file.txt
> 
> $ /cygdrive/c/Windows/system32/whoami /USER
> 
> USER INFORMATION
> ----------------
> 
> User Name    SID
> ============ ==============================================
> hp-z230\yano S-1-5-21-1515853178-1880514851-1804962447-1001
> 
> 
> The file server is not in AD and uses offline account in Windows 11
> (means no Microsoft Account). The client also uses offline account
> in Windows 10 too.
> The server and the client use the same user name and password, so
> authentication is automatically done.

It's not *that* automatic.  Your user SIDs are still different on
all standalone machines, so they are still different accounts, SID-wise.

> In this case, access() of the current cygwin wrongly refers to the
> permissions for 'others'.
> 
> I wonder why the NtAccessCheck() can not handle this situation
> correctly.

I really can't tell you, but there's
https://learn.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object
So, apparently, NtAccessCheck only checks the DACL against the
SID list in the user token.  In the above case, the ACL does not
contain your user account, nor one of the groups you're member
of.  So your account's access is the one for the Everyone entry.

> The process token does not have the privilege of the
> SIDs in the server side even though the authentication has been
> done by 'net use' command?

This is one of things puzzeling me for a while.  As soon as you
authenticate to some standalone server for SMB, your access token should
additionally contain the SID of the server account you authenticated as,
at least for file access.  But that's not the case.

I just stumbled over
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/access-checks-windows-apis-return-incorrect-results

It seems to suggest to use AuthZ in a certain way to check permissions.
Maybe we can replace NtAccessCheck with AuthZ?  If we're lucky, we might
even get away with the already existing code in the authz_ctx class
defined in sec/helper.cc.  If not, we may have to add another function
method calling AuthzInitializeRemoteResourceManager instead of
AuthzInitializeResourceManager.

Care to hack up a test?


Corinna