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: 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 List-Archive: List-Post: List-Help: List-Subscribe: , From: Ross Patterson via Cygwin Reply-To: Ross Patterson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Cygwin" 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