ACL weirdness on Cygwin

[Bruno Haible]

The test-copy-acl.sh test fails for me on Cygwin.

There appears to be a weird interaction between setting a file mode (chmod)
and setting an ACL. Although on this platform the ACL has entries that
correspond to user/group/other, the mode is *not* part of the ACL for all
files.

The test case showing that 'chmod' influences the ACL is this:

tmpfile4 is a regular file. One calls acl or facl on it with these entries:
  (gdb) print entries[0]
  $5 = {a_type = 1, a_id = 1006, a_perm = 6}
  (gdb) print entries[1]
  $6 = {a_type = 4, a_id = 513, a_perm = 0}
  (gdb) print entries[2]
  $7 = {a_type = 8, a_id = 0, a_perm = 1}
  (gdb) print entries[3]
  $8 = {a_type = 16, a_id = 4294967295, a_perm = 7}
  (gdb) print entries[4]
  $9 = {a_type = 32, a_id = 4294967295, a_perm = 4}

Then "getfacl tmpfile4" shows these entries:
  user::rw-
  group::---
  group:root:--x
  mask:rwx
  other:r--
Looks all right. Then do a chmod 604 on it. Then "getfacl tmpfile4" shows this:
  user::rw-
  group::r--
  group:root:--x
  mask:rwx
  other:r--
The "r--" for 'other' has been ORed to the permissions for 'group'!

But there is also an opposite case: setting an ACL changes the mode:

  $ echo foo > tmpfile0

  $ chmod 600 tmpfile0 

  $ ls -l tmpfile0 
  -rw------- 1 haible None 4 Jun 11 21:41 tmpfile0

  $ setfacl -m group:0:1 tmpfile0

  $ ls -l tmpfile0 
  -rw-------+ 1 haible None 4 Jun 11 21:41 tmpfile0

  $ getfacl tmpfile0 
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  group:root:--x
  mask:rwx
  other:---

  $ setfacl -m other:4 tmpfile0

  $ ls -l tmpfile0 
  -rw-r--r--+ 1 haible None 4 Jun 11 21:41 tmpfile0

  $ getfacl tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  group:root:--x
  mask:rwx
  other:r--

  $ chmod 600 tmpfile0

  $ ls -l tmpfile0 
  -rw-------+ 1 haible None 4 Jun 11 21:41 tmpfile0

  $ getfacl tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  group:root:--x
  mask:rwx
  other:---

  $ chmod 644 tmpfile0

  $ ls -l tmpfile0 
  -rw-r--r--+ 1 haible None 4 Jun 11 21:41 tmpfile0

  $ getfacl tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::r--
  group:root:--x
  mask:rwx
  other:r--

If you understand it, congratulations. I don't understand it.
Here's one more experiment, to make your head spin:

  $ echo foo > tmpfile0

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-r--r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::r--
  mask:rwx
  other:r--

  $ chmod 664 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-rw-r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::rw-
  mask:rwx
  other:r--

  $ setfacl -m group::0 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-r--r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  mask:rwx
  other:r--

  $ setfacl -m other::0 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw------- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  mask:rwx
  other:---

  $ setfacl -m group::4 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-r----- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::r--
  mask:rwx
  other:---

  $ setfacl -m group::0 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw------- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  mask:rwx
  other:---

  $ setfacl -m other::4 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-r--r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::---
  mask:rwx
  other:r--

  $ setfacl -m group::2 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-rw-r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::-w-
  mask:rwx
  other:r--

  $ chmod 664 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-rw-r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::rw-
  group::rw-
  mask:rwx
  other:r--

  $ chmod 064 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  ----rw-r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::---
  group::rw-
  mask:rwx
  other:r--

  $ setfacl -m other::4 tmpfile0 

  $ ls -l tmpfile0 ; getfacl tmpfile0 
  -rw-rw-r-- 1 haible None 4 Jun 11 22:02 tmpfile0
  # file: tmpfile0
  # owner: haible
  # group: None
  user::---
  group::rw-
  mask:rwx
  other:r--


It appears that a file can be in two states:
  A) the last chmod came after the last setfacl,
  B) the last setfacl came after the last chmod.
In case A) the chmod changed the ACL.
    user := mode_user
    group := mode_group
    other := mode_other
In case B) the setfacl changed the mode.
    mode_user := user | group | other,
    mode_group := group | other,
    mode_other := other
But how can you, by looking at a file, tell whether it's in state A or B?


I'm applying this fix. It makes the test suite pass. When I apply a similar
patch to set-mode-acl.c, then test-set-mode-acl.sh fails. So certainly it's
not the perfect solution, but at least the test suite passes.


2008-10-10  Bruno Haible  <address@hidden>

        * lib/copy-acl.c (qcopy_acl) [CYGWIN]: Call chmod before setting the
        ACL, not afterwards. Fixes test failure on Cygwin.

*** lib/copy-acl.c.orig 2008-10-11 03:21:14.000000000 +0200
--- lib/copy-acl.c      2008-10-11 02:51:14.000000000 +0200
***************
*** 336,341 ****
--- 336,351 ----
    did_chmod = 0; /* set to 1 once the mode bits in 0777 have been set */
    saved_errno = 0; /* the first non-ignorable error code */
  
+   if (!MODE_INSIDE_ACL)
+     {
+       /* On Cygwin, it is necessary to call chmod before acl, because
+        chmod can change the contents of the ACL (in ways that don't
+        change the allowed accesses, but still visible).  */
+       if (chmod_or_fchmod (dst_name, dest_desc, mode) != 0)
+       saved_errno = errno;
+       did_chmod = 1;
+     }
+ 
    /* If both ace_entries and entries are available, try SETACL before
       ACE_SETACL, because SETACL cannot fail with ENOTSUP whereas ACE_SETACL
       can.  */
***************
*** 345,351 ****
        ret = (dest_desc != -1
             ? facl (dest_desc, SETACL, count, entries)
             : acl (dst_name, SETACL, count, entries));
!       if (ret < 0)
        {
          saved_errno = errno;
          if (errno == ENOSYS && !acl_nontrivial (count, entries))
--- 355,361 ----
        ret = (dest_desc != -1
             ? facl (dest_desc, SETACL, count, entries)
             : acl (dst_name, SETACL, count, entries));
!       if (ret < 0 && saved_errno == 0)
        {
          saved_errno = errno;
          if (errno == ENOSYS && !acl_nontrivial (count, entries))
***************
*** 373,380 ****
    free (ace_entries);
  #  endif
  
!   if (!MODE_INSIDE_ACL
!       || did_chmod <= ((mode & (S_ISUID | S_ISGID | S_ISVTX)) ? 1 : 0))
      {
        /* We did not call chmod so far, and either the mode and the ACL are
         separate or special bits are to be set which don't fit into ACLs.  */
--- 383,390 ----
    free (ace_entries);
  #  endif
  
!   if (MODE_INSIDE_ACL
!       && did_chmod <= ((mode & (S_ISUID | S_ISGID | S_ISVTX)) ? 1 : 0))
      {
        /* We did not call chmod so far, and either the mode and the ACL are
         separate or special bits are to be set which don't fit into ACLs.  */