[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ACL weirdness on Cygwin
From: |
Bruno Haible |
Subject: |
ACL weirdness on Cygwin |
Date: |
Sat, 11 Oct 2008 04:00:59 +0200 |
User-agent: |
KMail/1.5.4 |
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. */
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- ACL weirdness on Cygwin,
Bruno Haible <=