on those file systems, rather than the default (for unknown file system
types) of issuing a warning and reverting to polling.
+** Build-related
+
+ root-only tests now check for permissions of our dummy user,
+ $NON_ROOT_USERNAME, before trying to run binaries from the build directory.
+ Before, we would get hard-to-diagnose reports of failing root-only tests.
+ Now, those tests are skipped with a useful diagnostic when the root tests
+ are run without following the instructions in README.
+
* Noteworthy changes in release 8.19 (2012-08-20) [stable]
fi
}
+# Test whether we can run our just-built rm setuidgid-to-root,
+# i.e., that $NON_ROOT_USERNAME has access to the build directory.
+setuidgid_has_perm_()
+{
+ local rm_version=$(
+ setuidgid $NON_ROOT_USERNAME env PATH="$PATH" rm --version |
+ sed -n 'ls/.* //p'
+ )
+ case ":$rm_version:" in
+ :$PACKAGE_VERSION:) ;;
+ *) return 1;;
+ esac
+}
+
require_root_()
{
uid_is_privileged_ || skip_ "must be run as root"
NON_ROOT_USERNAME=${NON_ROOT_USERNAME=nobody}
NON_ROOT_GROUP=${NON_ROOT_GROUP=$(id -g $NON_ROOT_USERNAME)}
+
+ # When the current test invokes setuidgid, call setuidgid_has_perm_
+ # to check for a common problem.
+ grep '^[ ]*setuidgid' "../$0" \
+ && { setuidgid_has_perm_ \
+ || skip_ "user $NON_ROOT_USERNAME lacks execute permissions"; }
}
skip_if_root_() { uid_is_privileged_ && skip_ "must be run as non-root"; }