DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 4AD9J14t343792 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 4AD9J14t343792 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=KcUpPVu3 X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED9013858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1731489540; bh=i/RsQY1int/70itIZIHM49mLQy1aTvvAb3XRiznvVU4=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=KcUpPVu34URx+1ATRZhQQT7Xp1aBEPm6wPlwqk7j2Di5WCQ3N7Dyjg3Pus2uPaAK+ wkd/yStAksZsctTKEfMAHp6cu/K5Nh6GXs7szRfl+kZU/gQvjqX/qmQ/r/Sny0A2h4 DsyaLGGGkKtVsa/6tIUQXWCN+sDMICv+QSNfLdHc= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EF5303858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EF5303858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731489485; cv=none; b=gOgB/8K//R7TlMeZQW1uDQBGkazwUon7UY9A8L0z4fVb0vEo0sTN3ylMeMoSl9pqONChQe8jbV85yshhPFAr/s1K78GsLXs0zvipqAq02s+4cVtyf2Ut/bFCr473wAwvNO5nfC2xs2dC5mC8ePJ7Xuif4/HIPHOij2qRwHqO3yI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731489485; c=relaxed/simple; bh=S6gry7YelYConKJ2rH4ktnHXv1Kb9XIvtbrcsUTUo7c=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=th+4IBa2TMZKfl7/Q0zZ/4ef7OtiYKEkbL0pySvukwjNcg6Ejb/8Z8NeQaVE5ntiWNt6cGWtfPW25LHWo2P3VkLjiI1tr5D3zbcw5n7wBvbLIsetLTgYYfKTRxVqwfQ3GASiFXdZJjJjazGODhhkyffW+wgU0EmkN1LDq/OS/gE= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Wed, 13 Nov 2024 18:17:55 +0900 To: cygwin AT cygwin DOT com Subject: Re: SMBFS mount's file cannot be made executable Message-Id: <20241113181755.02289e8e8d9af7e19e8f4387@nifty.ne.jp> In-Reply-To: References: <20241111193152 DOT c3a81044a03ecf2093185166 AT nifty DOT ne DOT jp> <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> <20241111211953 DOT 605b186566ce3a44ca929788 AT nifty DOT ne DOT jp> <20241112042937 DOT 740185a42d476993b4b1e31c AT nifty DOT ne DOT jp> <20241112175427 DOT 750ae77a8086594a765862c5 AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Hi Corinna, On Tue, 12 Nov 2024 12:56:15 +0100 Corinna Vinschen wrote: > 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? I'm working on this, however, I stuck on setting the first parameter of AuthzInitializeRemoteResourceManager(). The most members of structure AUTHZ_RPC_INIT_INFO_CLIENT are PWSTR, and I have no idea what kind of string should be set to each member. Especially Endpoint and ServerSpn. typedef struct _AUTHZ_RPC_INIT_INFO_CLIENT { USHORT version; PWSTR ObjectUuid; PWSTR ProtSeq; PWSTR NetworkAddr; PWSTR Endpoint; PWSTR Options; PWSTR ServerSpn; } AUTHZ_RPC_INIT_INFO_CLIENT, *PAUTHZ_RPC_INIT_INFO_CLIENT; Do you have any idea? -- Takashi Yano -- 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