This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

Not sure what Transmission is, but files downloaded with POSIX
tools are usually not executable.  For instance, download Cygwin's
setup-x86.exe with wget.  Then try to execute it.  It won't since
the permissions are set according to your umask and without execute
permissions, e.g., 0644.  This is normal.
The behavior has changed with the ACL change in Cygwin and I would not consider that "normal". The warning from Windows is not normal.

I realize that the previous implementation was already problematic and messed with permissions but I did not notice it since it never denied executing executables.

The permissions must *not* be reordered.  If Cygwin creates permissions
incorrectly it's one thing, but the order to emulate POSIX permissions
is non-canonical.  Reordering them will break them.

Please provide the exact output from icacls.
They *have* to be reordered to be modifiable in Windows/Explorer. In other words, if I want to change permission the new ACL behavior ensures that it breaks the Cygwin permissions?

Here is the output from icacls /saveacl for some file:

After letting Windows fix the order:

Here is what's "normal" for Windows if I create a file under a new folder on C: in Explorer:

Strangely enough this is displayed as "-rwxrwx---+ MyUser None" with `ls -l` even though my user is in the group Administrators.

Here is what I would expect:
MyUser is in the group Administrators. Given the inherited permissions above a Windows-created file should be shown as "-rwxrwxr--+ MyUser Administrators"?

After chmod 664 I would expect this:
- still inherit all the permissions
- add permission MyUser DENY execute
- add permission Administrators DENY execute
- add permission Everyone ALLOW read

Instead Cygwin copies all permissions, drops the inheritance, copies them again, adds None, adds NULL SID ...

After a consecutive chmod 770 I would expect the above non-inherited permissions to be removed again.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]