Potential Bug: Created files list owner/user exec until Windows reorders permissions

Ross Patterson me@rpatterson.net
Thu May 23 16:35:40 GMT 2024


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


More information about the Cygwin mailing list