[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI: avoid strange new test failure
From: |
Jim Meyering |
Subject: |
FYI: avoid strange new test failure |
Date: |
Tue, 08 Jan 2008 15:55:59 +0100 |
buildbot reported a coreutils test failure in a new test, e.g.,
http://buildbot.proulx.com:9000/i686%20gnu-linux%20full/builds/371/step-test/0
make check-TESTS
make[3]: Entering directory
`/usr/local/build/coreutils/build-i686-gnu-linux-full/build/project/build/tests/cp'
make[4]: Entering directory
`/usr/local/build/coreutils/build-i686-gnu-linux-full/build/project/build/tests/cp'
FAIL: parent-perm.log
At first I thought it was my fault, i.e., a bug in the test,
due to not handling the sticky dir. bit.
And I suppose technically it is, but...
I reproduced the problem:
Starting in a directory with the sticky bit set,
create a directory and show it inherits the sticky bit:
$ mkdir a
$ ls -ld a
drwxr-sr-x 2 buildbot build 4096 2008-01-08 06:35 a
Try to copy that empty dir, with all its attributes to a new name:
$ strace cp -a a b
...
chmod("b", 042755) = 0
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
Process 20618 detached
Show that the sticky attribute has been lost:
$ ls -ld b
drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b
Try to apply it manually:
$ strace chmod g+s b
...
chmod("b", 02755) = 0
fchdir(3) = 0
close(3) = 0
close(1) = 0
exit_group(0) = ?
Process 14188 detached
That doesn't work either. And still no failure.
$ ls -ld b
drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b
$ ls -ld a
drwxr-sr-x 2 buildbot build 4096 2008-01-08 06:35 a
Notice that this user is not a member of the group, "build":
$ id -a
uid=105(buildbot) gid=65534(nogroup) groups=65534(nogroup)
Confirm that it's due to the way the underlying chmod syscall works:
$ perl -e 'chmod 02755, "b" or die'
$ ls -ld b
drwxr-xr-x 2 buildbot build 4096 2008-01-08 06:35 b
Yep, in this case, the S_ISGID bit is ignored.
And this behavior is even allowed by POSIX, though the
exclusion loophole there is big enough to drive a truck through.
The Linux "man 3 chmod" page says essentially the same thing:
Additional implementation-defined restrictions may cause the S_ISUID
and S_ISGID bits in mode to be ignored.
So I've changed the test to accommodate this ugliness:
2008-01-08 Jim Meyering <address@hidden>
parent-perm: avoid a bizarre test failure.
* tests/cp/parent-perm: Accommodate the situation in which
chmod ("dir", 02755) returns 0 yet fails to set the S_ISGID bit.
diff --git a/tests/cp/parent-perm b/tests/cp/parent-perm
index 1c7a222..cedcac4 100755
--- a/tests/cp/parent-perm
+++ b/tests/cp/parent-perm
@@ -33,6 +33,15 @@ cp -p --parent a/b/d/foo e || fail=1
# Ensure that permissions on just-created directory, e/a/,
# are the same as those on original, a/.
-test $(stat --printf %A a) = $(stat --printf %A e/a) || fail=1
+
+# The sed filter maps any 's' from an inherited set-GID bit
+# to the usual 'x'. Otherwise, under unusual circumstances, this
+# test would fail with e.g., drwxr-sr-x != drwxr-xr-x .
+# For reference, the unusual circumstances is: build dir is set-gid,
+# so "a/" inherits that. However, when the user does not belong to
+# the group of the build directory, chmod ("a/e", 02755) returns 0,
+# yet fails to set the S_ISGID bit.
+test $(stat --printf %A a|sed s/s/x/g) = $(stat --printf %A e/a|sed s/s/x/g) ||
+ fail=1
(exit $fail); exit $fail
--
1.5.4.rc2.61.g6ed4e
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- FYI: avoid strange new test failure,
Jim Meyering <=