DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 4ACBufXI4137362
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 4ACBufXI4137362
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=QfITh2ma
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 0310E3858CDB
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1731412600;
	bh=OY4V5kez1kz5pz3vYL9QfY4ttYOcRSMIFmDj0/+K6Ig=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=QfITh2ma3zpeaNCOo40GrS8M9+z59W9RGXX+RZPMwnCacWaw/zLLpQcYqI1Oqzczk
	pZWVJqome7kYlRZxQoEvm+L98eMl3Y6HfrWqisjSneW5sV/NgNiDRCKhUCLIDHVj2Z
	b2Bj4YE4dOlS+cQy73teamSaDN1Z3XURzm7ymvR0=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 68FDE3858D20
Date:	Tue, 12 Nov 2024 12:56:15 +0100
To:	cygwin AT cygwin DOT com
Subject:	Re: SMBFS mount's file cannot be made executable
Message-ID:	<ZzNCXz3o9k40U9zA@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20241111193152 DOT c3a81044a03ecf2093185166 AT nifty DOT ne DOT jp>
	<ZzHizX_6FXABDPvZ AT calimero DOT vinschen DOT de>
	<20241111201928 DOT 811a2f8f09142b7aa8fe9bdc AT nifty DOT ne DOT jp>
	<20241111203202 DOT b22bcf4f9030aff58299fe0e AT nifty DOT ne DOT jp>
	<20241111204051 DOT 493f12208bb59d62b699dd28 AT nifty DOT ne DOT jp>
	<ZzHyhoWnNvkTQYW- AT calimero DOT vinschen DOT de>
	<20241111211953 DOT 605b186566ce3a44ca929788 AT nifty DOT ne DOT jp>
	<ZzIIO2NxmdYpox2A AT calimero DOT vinschen DOT de>
	<20241112042937 DOT 740185a42d476993b4b1e31c AT nifty DOT ne DOT jp>
	<20241112175427 DOT 750ae77a8086594a765862c5 AT nifty DOT ne DOT jp>
MIME-Version:	1.0
In-Reply-To:	<20241112175427.750ae77a8086594a765862c5@nifty.ne.jp>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 4ACBufXI4137362

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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -