[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: umask also influences test/rm/fail-2eperm
From: |
Jim Meyering |
Subject: |
Re: umask also influences test/rm/fail-2eperm |
Date: |
Fri, 04 May 2007 13:34:20 +0200 |
address@hidden wrote:
>> From address@hidden Fri May 4 12:04:56 2007
> ...
>> address@hidden wrote:
>> > coreutils-6.9/tests/rm/fail-2eperm needs a 'chmod 644 a/b' or equivalent
>> > after the 'touch a/b || framework_failure=1' to be able to cope with
>> > different umasks.
>> > No idea though why it had shown up sometimes, not othertimes, with the
>> > same umask=000.
>>
>> Since I am unable to reproduce that, I'm reluctant to change anything
>> without understanding the problem. Can you provide more detail?
>
> When looking at the test, I can understand why 'chmod 644 a/b' should
> be called so that the test can cope with different umasks. What I don't
> understand yet is why umask doesn't propagate to this test, depending on
> what happeded before. But does it matter? The test should probably work
> with any umask, so all u,g, and o bits should be set to a predefined
> state and not left to random influences. I guess you should be able
> to reproduce the problem it if you put 'umask 000' at the beginning,
> into the test itself.
Oh! I made the same mistake.
To reproduce *that* failure you need to specify an unusable umask.
E.g., one that prohibits any of the owner rwx bits:
umask 777
Sure, I could work around such silliness by simply adding this
near the beginning:
# Protect against a ridiculously restrictive umask.
umask 077
However, I'm not sure it's worthwhile, since no one would use a umask
prohibiting any of u=rwx for long. And a similar change would be
required for most other tests.
If you can make it fail with a umask affecting only group/other
bits, then please let me know.
> Also, the problem in tests/ls/color-dtype-dir turns out to be related
> to umask, too: for the same reason as in the above two tests (defined state
> of all bits), the two lines
> chmod o+w other-writable || framework_failure=1
> chmod o+t sticky || framework_failure=1
> can be replaced by
> chmod 757 other-writable || framework_failure=1
> chmod 1755 sticky || framework_failure=1
> (or equivalent symbolic versions of 757 and 1755) and then that (non-root
> test)
> also passes.
Thanks for pointing that out.
For the record, I can reproduce the failure with this umask, among others:
$ (umask 1; make -C ls check TESTS=color-dtype-dir)
make: Entering directory `/f/w/cu/tests/ls'
make check-TESTS
make[1]: Entering directory `/f/w/cu/tests/ls'
out exp differ: char 9, line 1
1c1
< ^[[0m^[[34;42md^[[0m$
---
> ^[[0m^[[01;34md^[[0m$
4c4
< ^[[30;42msticky^[[0m$
---
> ^[[37;44msticky^[[0m$
FAIL: color-dtype-dir
I fixed it like this:
Avoid test failure when run with an unusual umask.
* tests/ls/color-dtype-dir: Set umask to 022.
Suggestion from AIDA Shinra.
diff --git a/tests/ls/color-dtype-dir b/tests/ls/color-dtype-dir
index f3f9ee9..41c8bf3 100755
--- a/tests/ls/color-dtype-dir
+++ b/tests/ls/color-dtype-dir
@@ -4,7 +4,7 @@
# directories the same as the first one -- but only on a file system
# with dirent.d_type support.
-# Copyright (C) 2006 Free Software Foundation, Inc.
+# Copyright (C) 2006-2007 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -33,6 +33,9 @@ t0=`echo "$0"|sed 's,.*/,,'`.tmp; tmp=$t0/$$
trap 'status=$?; cd "$pwd" && chmod -R u+rwx $t0 && rm -rf $t0 && exit
$status' 0
trap '(exit $?); exit $?' 1 2 13 15
+# Don't let a different umask perturb the results.
+umask 22
+
framework_failure=0
mkdir -p $tmp || framework_failure=1
cd $tmp || framework_failure=1