DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 44NGaMtN2890460
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=Q22230CO
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org A4243386545E
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1716482180;
	bh=DE62i9r9V4IVa0644B+eCqSQcYssuqdPkSosxl85l64=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	List-Help:List-Subscribe:From:Reply-To:From;
	b=Q22230COchKf21DEWrBacUjEQLITWlvTHtM62Wl5k9JGi8756XA3AS43OrnlHnbPK
	AlpZmsvOqM8Tu/g/YxF50DkBr+QmZnUEJEcwJv0G/ZIBT3EqBmh2fiHl2FBYVXGtTD
	AsVI0LifwfDRaBnSXyV5IK2GQE/qIjb/tzjDzSmI=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 1510D38650D1
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 1510D38650D1
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716482157; cv=none;
	b=Jo7Hf5rYG84pwfl2MzTDOxqss+ygfOUv+fFRNQUa+miHbmh641venv55pQx3vTIVq1zg1J4dTesCgssw7rwkrEoyPb9wSoSWT3T7KZrmRX7C3wF15pYbG0BHCNWZs51cwgtHrVZcAo1KRCQby9YS50k+5iesUHIiDHwVhQsXDmQ=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1716482157; c=relaxed/simple;
	bh=JKMgGMlfj1sMUfYKQ9FmlJsOr09FzizSPN+DKh6c6iI=;
	h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
	b=iv31xXLZiqbZDramCN8DtYPY566vcKPv5cN7G8Dtifx0YUAxL9Xv8mRinz+gBpRduS/XEsFLugEurZCQALjK7YQYF4IvKKPL/1eIL+PfZuaBlEp4LwL3IXA+o4UPMuxfMA6Us+k1Q25gxxp7LU7QckeTw3udmMolN5teD8Hwq8M=
ARC-Authentication-Results:	i=1; server2.sourceware.org
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1716482153; x=1717086953;
	h=to:subject:message-id:date:from:mime-version:x-gm-message-state
	:from:to:cc:subject:date:message-id:reply-to;
	bh=qI3NfBSOmDU2FPTLWY2Go7pJaoxthw7vxKM67K+mJGk=;
	b=klslykKc95DHoSbzjw7QxoZvfzyUKKCXIuJFmcKq6ngXEKIfQSwIPFMNMlezI43xET
	HFqfWpUR0BqE305uoKbDGtNMuT3qovPHWum93zwRb6W/uPBAvWvh+86sz8izL8WWzjPD
	L4I2mtFL58slEmj7JWjgJWf9428Xv+hGpZQngUzhz607AAEfHYhWJHxNAUsrYF2i60bi
	TQcngUj0A7LZXpKRjYBG1M7kB1t4oOL76FkSIwnwWh7uZBDxLw7/BF+l/Q2i4j5bHDLD
	uqPLwB5nHKcHXvn2wqRXX3+ShPWW372abaaZ37gcKsCixBy8J7SHeHpiB/0wQEGYP09Y
	rOZQ==
X-Gm-Message-State:	AOJu0Yxy5nBki9oaeUlYu7eM8ei5Ufg0j8YSsLBUARPhBO/8AnzXXcnn
	mdv58eslp7H/41hd4VfUwU0Mb3H0CvmkPm3G/wV+7K67vAsZvbNgVFDBz6Ve8UA57IIkvvi8DS9
	lUonv5fM0Y2MvjA+WlK2XpCNZD7G1IaQIhCV/OIPmW0AlMV7Uyag=
X-Google-Smtp-Source:	AGHT+IHoogL1b7ukB7oFORABy2ij3M7N2xbyceWL3fV7P0vRprOQElq2IDROE/X74dZtQvL4oRPkIrKWsmn7a6XNhU4=
X-Received:	by 2002:a05:6870:c154:b0:24c:5dc1:a878 with SMTP id
	586e51a60fabf-24c68b5cdf4mr5859895fac.23.1716482152410; Thu, 23 May 2024
	09:35:52 -0700 (PDT)
MIME-Version:	1.0
Date:	Thu, 23 May 2024 09:35:40 -0700
Message-ID:	<CAGJ7yHBsoOoaX+mWmS8OUv8DtzjGwcbGCtisVvfga-C-ff005Q@mail.gmail.com>
Subject:	Potential Bug: Created files list owner/user exec until Windows
	reorders permissions
To:	cygwin AT cygwin DOT com
X-Spam-Status:	No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
	TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
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-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:	Ross Patterson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Ross Patterson <me AT rpatterson DOT net>
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

TL;DR: Weird permissions behavior in a Cygwin installation where
permissions have been changed over time. I can't reproduce it on a
clean install so that's how I'm working around it, but I thought it
might be worth capturing what details I have in case it helps others
or helps identify a bug.

After creating a file for the first time under a Cygwin bash shell,
Cygwin lists it as executable by the owner/user:

    $ ls -ld /foo-0.txt
    ls: cannot access '/foo-0.txt': No such file or directory
    $ touch /foo-0.txt && ls -ld /foo-0.txt
    -rwxrw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt

Changing it's mode in Cygwin reports success but Cygwin still lists it
as executable:

    $ chmod -c u-x /foo-0.txt && ls -ld /foo-0.txt
    mode of '/foo-0.txt' changed from 0764 (rwxrw-r--) to 0664 (rw-rw-r--)
    -rwxrw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt

Note that the resulting Windows DACLS do indeed seem confused about
whether the owner should be granted or denied execution:

    $ icacls "$(cygpath -w ./foo-0.txt)"
    foo-0.txt NULL SID:(DENY)(Rc,WEA,X,DC)
              MEDIA\xen:(R,W,D,WDAC,WO)
              MEDIA\xen:(DENY)(X)
              NT AUTHORITY\Authenticated Users:(DENY)(X)
              NT AUTHORITY\SYSTEM:(DENY)(X)
              BUILTIN\Administrators:(DENY)(X)
              BUILTIN\Users:(DENY)(X)
              MEDIA\me:(DENY)(X)
              MEDIA\xen:(RX)
              NT AUTHORITY\Authenticated Users:(RX,W)
              NT AUTHORITY\SYSTEM:(RX,W)
              BUILTIN\Administrators:(RX,W)
              BUILTIN\Users:(RX)
              MEDIA\me:(RX,W)
              Everyone:(R)

    Successfully processed 1 files; Failed processing 0 files

After opening the file's properties in the Windows GUI, I let Windows
reorder the DACLs to canonical order by clicking the `Advanced` button
on the `Security` tab, clicking the `Reorder` button in the resulting
modal, and then clicking the `Apply` button. After that, Cygwin lists
the permissions as expected:

    $ ls -ld /foo-0.txt
    -rw-rw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt

I don't have much experience with the Windows security model, nor any
depth of technical understanding of either Windows or Cygwin, but this
sure seems to contradict [the in-depth "File permissions" description
concerning how Cygwin orders the
DACLs](https://cygwin.com/cygwin-ug-net/ntsec.html) to reconcile the
POSIX and Windows security models as best as possible. I've also done
a bunch of other reading from Google searches, mostly the Cygwin
mailing list and Stack Exchanges, and much of that is regarding the
executable permission but I didn't find anything regarding this
specific behavior. Of course, I didn't read everything that might
match this, there are just too many hits.

Finally, I fired up [the Windows 11 developer VirtualBox appliance VM
image](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/),
and installed Cygwin. I chose the chocolatey package because its
Cygwin version is more current than wget's. I could *not* reproduce
this behavior in that clean Cygwin installation, so I opted to
workaround the issue by re-installing.

The Windows permissions in the Cygwin installation that exhibits the
above behavior have been changed over time, though I don't recall the
specifics. In particular, when compared to the clean install, I noted
that the Cygwin root folder had been set to inherit it permissions
from `C:\` and that those inherited DACLs differed from the clean
install.. FWIW, when I disabled inheritance and copied the inherited
permissions to the Cygwin root, I could still reproduce this behavior:

    $ icacls "$(cygpath -w ./)"
    .\ NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
       NT AUTHORITY\SYSTEM:(OI)(CI)(F)
       BUILTIN\Administrators:(OI)(CI)(F)
       MEDIA\me:(OI)(CI)(F)
       BUILTIN\Users:(OI)(CI)(RX)

    Successfully processed 1 files; Failed processing 0 files

Hope this helps someone somehow ;-)
Ross

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