coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] tests: improve test for a working setfacl


From: Bernhard Voelker
Subject: [PATCH] tests: improve test for a working setfacl
Date: Fri, 10 Jan 2014 17:04:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

As a side note for work around needed for setfacl below, i.e., the odd
behavior of only invoking the syscall if there would be change, I want
to mention that this is another reason for chmod, chown, etc. to continue
doing the system call instead of trying to optimize in user space, as
recently discussed.

Have a nice day,
Berny


>From 5d7591d0edf0dd31c2daa195ee766c1383b89f4c Mon Sep 17 00:00:00 2001
From: Bernhard Voelker <address@hidden>
Date: Fri, 10 Jan 2014 16:48:25 +0100
Subject: [PATCH] tests: improve test for a working setfacl

Prompted by a test framework failure of tests/mkdir/p-acl.sh on armv7l:
The previous test for a working setfacl was not sufficient in some
circumstances.

* init.cfg (require_setfacl_): Call setfacl twice with conflictive
ACL specs, and use ACL specs which can't be mapped into regular file
permission bits.  Document the reasons.
---
 init.cfg | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/init.cfg b/init.cfg
index 10fee4e..af3963c 100644
--- a/init.cfg
+++ b/init.cfg
@@ -192,9 +192,37 @@ require_valgrind_()
     skip_ "requires a working valgrind"
 }

+# Skip the current test if setfacl doesn't work on the current file system,
+# which could happen if not installed, or if ACLs are not supported by the
+# kernel or the file system, or are turned off via mount options.
+#
+# Work around the following two issues:
+#
+# 1) setfacl maps ACLs into file permission bits if on "noacl" file systems.
+#
+# On file systems which do not support ACLs (e.g. ext4 mounted with -o noacl),
+# setfacl operates on the regular file permission bits, and only fails if the
+# given ACL spec does not fit into there.  Thus, to test if ACLs really work
+# on the current file system, pass an ACL spec which can't be mapped that way.
+# "Default" ACLs (-d) seem to fulfill this requirement.
+#
+# 2) setfacl only invokes the underlying system call if the ACL would change.
+#
+# If the given ACL spec would not change the ACLs on the file, then setfacl
+# does not invoke the underlying system call - setxattr().  Therefore, to test
+# if setting ACLs really works on the current file system, call setfacl twice
+# with conflictive ACL specs.
 require_setfacl_()
 {
-  setfacl -m user::rwx . \
+  local d='acltestdir_'
+  mkdir $d || framework_failure_
+  local f=0
+
+  setfacl -d -m user::r-x $d \
+    && setfacl -d -m user::rwx $d \
+    || f=1
+  rm -rf $d || framework_failure_
+  test $f = 0 \
     || skip_ "setfacl does not work on the current file system"
 }

-- 
1.8.4.2




reply via email to

[Prev in Thread] Current Thread [Next in Thread]