DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 4AC8uOON4088599
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24C353858CDB
Date: Tue, 12 Nov 2024 17:54:27 +0900
To: cygwin@cygwin.com
Subject: Re: SMBFS mount's file cannot be made executable
Message-Id: <20241112175427.750ae77a8086594a765862c5@nifty.ne.jp>
In-Reply-To: <20241112042937.740185a42d476993b4b1e31c@nifty.ne.jp>
References: <BL0PR0901MB430827F1A0668E468B498FBBA5D70@BL0PR0901MB4308.namprd09.prod.outlook.com>
 <20241108205109.55f99e2d172b9fc87e92ae67@nifty.ne.jp>
 <Zy4ODHHpmZPggGSz@calimero.vinschen.de>
 <20241111193152.c3a81044a03ecf2093185166@nifty.ne.jp>
 <ZzHizX_6FXABDPvZ@calimero.vinschen.de>
 <20241111201928.811a2f8f09142b7aa8fe9bdc@nifty.ne.jp>
 <20241111203202.b22bcf4f9030aff58299fe0e@nifty.ne.jp>
 <20241111204051.493f12208bb59d62b699dd28@nifty.ne.jp>
 <ZzHyhoWnNvkTQYW-@calimero.vinschen.de>
 <20241111211953.605b186566ce3a44ca929788@nifty.ne.jp>
 <ZzIIO2NxmdYpox2A@calimero.vinschen.de>
 <20241112042937.740185a42d476993b4b1e31c@nifty.ne.jp>
Mime-Version: 1.0
Precedence: list
From: Takashi Yano via Cygwin <cygwin@cygwin.com>
Reply-To: Takashi Yano <takashi.yano@nifty.ne.jp>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Tue, 12 Nov 2024 04:29:37 +0900
Takashi Yano wrote:
> On Mon, 11 Nov 2024 14:35:55 +0100
> Corinna Vinschen wrote:
> > On Nov 11 21:19, Takashi Yano via Cygwin wrote:
> > > On Mon, 11 Nov 2024 13:03:18 +0100
> > > Corinna Vinschen wrote:
> > > > On Nov 11 20:40, Takashi Yano via Cygwin wrote:
> > > > > On Mon, 11 Nov 2024 20:32:02 +0900
> > > > > Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> > > > > > Even with this patch, the file:
> > > > > > 
> > > > > > yano $ touch samba_test_file.txt
> > > > > > yano $ ls -l samba_test_files.txt
> > > > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt
> > > > > 
> > > > > Oops! This was wrong.
> > > > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 samba_test_file.txt
> > > > 
> > > > That's Samba for you.  I applied your patch and created a file
> > > > on my share, and the Authenticated Users group was not in the
> > > > resulting ACL.  Only user, group, and Everyone.
> > > > 
> > > > Either way, I don't think this is the right thing to do.  Even if
> > > > the group isn't added to the ACL on my machine, it still loks like
> > > > a security problem in waiting.
> > > 
> > > Isn't this DACL here used only for access_check() (NtAccessCheck())?
> > > In my environment, the Authenticated Users does not appear in the ACL
> > > too.
> > 
> > Oh, yeah, right, *blush*.
> > 
> > But it's still not the right thing to do.  You convert the Samba ACL
> > to a Windows ACL which gives Authenticated Users full permissions.
> > So the check_access() function will return false positives, because
> > every authenticated user is in the Authenticated Users group and has
> > supposedly FILE_ALL_ACCESS.  Even if the actual function (read, write,
> > execute) will fail, the access() function will claim that every
> > authenticated user has RWX perms.
> 
> Ah, right. I have just confirmed that behaviour...
> 
> > AFAICS, the underlying problem is somehow the user mapping.  Did you
> > try with username map = /foo/bar?
> 
> Yes. However, my user name is 'yano' both in server (Linux) and
> client (Windows 10) side. So, I think there is no effect of
> 'username map'.

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.

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. 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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

-- 
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