Cygwin's ACL handling is NOT interoperable with Windows

[Stefan Kanthak]

Hi,

<https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files> states:

| 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
| permissions.
...
| 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
  CopyFile() <https://msdn.microsoft.com/en-us/library/aa220078.aspx>
  API (just to pick 3 examples) bring INHERITED ACEs into their PROPER
  canonical order.

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

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

* 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?
OUCH³!


Win32 functions like CreateFile() and CreateDirectory()
(see <https://msdn.microsoft.com/en-us/library/aa363858.aspx>
and <https://msdn.microsoft.com/en-us/library/aa363855.aspx>)
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
handled.

The documentation of other Win32 functions, for example
AddAccessAllowedAce() and AddAccessDeniedAce()
(see <https://msdn.microsoft.com/en-us/library/aa374947.aspx>
and <https://msdn.microsoft.com/de-de/library/aa374962.aspx>)
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/aa374951.aspx> and
<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.

<https://msdn.microsoft.com/en-us/library/aa379298.aspx>
<https://msdn.microsoft.com/en-us/library/aa446683.aspx>
<https://technet.microsoft.com/en-us/library/cc781716.aspx>

| 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
      <https://blogs.msdn.microsoft.com/oldnewthing/20070608-00/?p=26503>

      Also see <http://www.ntfs.com/ntfs-permissions-acl-use.htm>

Fix Cygwin's BUGGY ACL creation!

regards
Stefan Kanthak

PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api>
    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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple