"Kyle J. McKay" <mack...@gmail.com> writes:

> I ran into this problem.  It seems like (at least on older Mac OS X)  
> that the root directory is created like so:
>
>    drwxrwxr-t  39 root  admin  /
>
> And since the first (and likely only user) on Mac OS X is a member of  
> the admin group, the SANITY test fails and complains even though  
> you're not running as root (the failure message is misleading).

The design choice Mac OS X makes around filesystems may deserve the
!SANITY label ;-) but we may want to tighten the check for SANITY,
or better yet, rethink the interaction between POSIXPERM and SANITY.

What we want to express with SANITY is:

        On this system, if the user who is running the test
        does not have write permission to a file, write to such a
        file would fail.

So running our tests as a non-root admin user should be labeled as
being sane.  We just use a more expedient "if you can write into the
root directory, you must be root, asit is crazy to allow non-root
user to 'mv /etc /foo && mkdir /etc && write /etc/passwd'"
heuristics which is old-school.

This should not be the final patch (I think it should become a lazy
prereq as it does a lot more), but just for testing, how does this
look?

 t/test-lib.sh | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index bb1402d..cdafab5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1033,7 +1033,16 @@ test_lazy_prereq USR_BIN_TIME '
 
 # When the tests are run as root, permission tests will report that
 # things are writable when they shouldn't be.
-test -w / || test_set_prereq SANITY
+if test_have_prereq POSIXPERM &&
+       ! test -w / &&
+       >sanitytest &&
+       chmod a= sanitytest &&
+       ! (>sanitytest) 2>/dev/null &&
+       chmod +w sanitytest &&
+       rm -f sanitytest
+then
+       test_set_prereq SANITY
+fi
 
 GIT_UNZIP=${GIT_UNZIP:-unzip}
 test_lazy_prereq UNZIP '
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to