Cygwin's ACL handling is NOT interoperable with Windows
- Date: Sat, 4 Aug 2018 19:11:28 +0200
- From: "Stefan Kanthak" <stefan.kanthak@xxxxxxxx>
- Subject: Cygwin's ACL handling is NOT interoperable with Windows
| There's just one problem when trying to map the POSIX permission model
| onto the Windows permission model.
| Canonical ACLs are unable to reflect each possible combination of POSIX
| Again: This works on all supported versions of Windows. Only the GUIs
| aren't able (or willing) to deal with that order.
These last two statements are wrong:
* the first statement holds ONLY because of the LIMITATION of the POSIX
permissions; it is WRONG for the general case, which ALL Windows
interfaces/components need to consider and handle, EVERYWHERE!
* the second statement is a blatant lie: to guarantee CORRECT
interpretation of arbitrary ACLs, ALL Windows interfaces/components,
not just the "GUIs", MUST create CANONICAL ACLs only.
This especially means that not just Windows Explorer, but also the
command processor with its builtin COPY command as well as the
API (just to pick 3 examples) bring INHERITED ACEs into their PROPER
As Cygwin is a guest in the house of Windows, it should respect its hosts
house rules; instead it but violates them, and blames the host for its
| But don't even think of pressing OK...
Fortunately nobody need to press OK here, but everybody can demonstrate
Cygwin's defects as follows:
* Use Windows Explorer, the command processor or CopyFile() to copy an
arbitrary file into a directory created by Cygwin, then inspect its
* Use Windows' Explorer, the command processor or CopyFile() to copy an
arbitrary file created by Cygwin into an arbitrary directory created
by Cygwin, then inspect its ACL.
* Use Windows Explorer or the command processor to create a subdirectory
in a directory created by Cygwin, then inspects its ACL!
Do these ACLs reflect the intended or expected POSIX permissions?
Win32 functions like CreateFile() and CreateDirectory()
allow to write NON-canonical ACLs via direct specification of a
"security descriptor"; if NULL is specified (which is the typical
case), they create canonical ACLs, reordering inherited ACEs!
Unfortunately their documentation misses remarks on the proper
canonical order of ACLs, and how inherited but UNORDERED ACLs are
The documentation of other Win32 functions, for example
AddAccessAllowedAce() and AddAccessDeniedAce()
but EXPLICITLY states:
| These functions do not automatically place the new ACE in the
| proper canonical order. It is the caller's responsibility to
| ensure that the ACL is in canonical order by adding ACEs in the
| proper sequence.
<https://msdn.microsoft.com/en-us/library/aa374964.aspx> go further:
| The caller must ensure that ACEs are added to the DACL in the
| correct order. For more information, see Order of ACEs in a DACL.
| The canonical order ensures that an explicit access-denied ACE is
| enforced regardless of any explicit access-allowed ACE.
JFTR: for the algorithm used in Windows and why the proper order of
ACLs is crucial see
Also see <http://www.ntfs.com/ntfs-permissions-acl-use.htm>
Fix Cygwin's BUGGY ACL creation!
too states bloody lies:
| The Windows subsystem only supports CWD paths of up to 258 chars.
The Win32 API supports pathnames with up to 32767 (Unicode) characters;
this includes of course the CWD!
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple