The cramfs doubles/mkfs/mkfs-endianness tests set "umask 133" to get
deterministic permission bits on the test input files. The umask was
never restored, so it stayed in effect for every command run later in
the test, including the build-tree mount/umount/mkfs.cramfs helpers.
When such a helper is a libtool wrapper script that has to relink its
real binary on first use (fast_install=yes), the relink runs under the
leaked umask 133 and the resulting .libs/lt-* binary is created without
execute bits (mode 0644). The wrapper then fails to exec it with
"Permission denied" (EACCES). Because the broken binary is cached, every
subsequent test using that helper fails as well:
exec: .../.libs/lt-mount: cannot execute: Permission denied
Save and restore the umask so it only covers creation of the test input
files and does not affect helper invocations.
rm -rf "$IMAGE_SRC"
mkdir -m 755 -p $IMAGE_SRC
+umask_saved=$(umask)
umask 133
echo hello > $IMAGE_SRC/a
echo hello > $IMAGE_SRC/b
+umask "$umask_saved"
+
# sudo may use whatever group
chgrp -R 0 "$IMAGE_SRC"
rm -rf "$IMAGE_SRC"
mkdir -m 755 -p $IMAGE_SRC
+umask_saved=$(umask)
umask 133
for d in `seq 0 110`; do
done
done
+umask "$umask_saved"
+
chgrp -R 0 "$IMAGE_SRC"
ts_cd "$IMAGE_SRC"
IMAGE_DATA="$TS_OUTDIR/${TS_TESTNAME}-data"
IMAGE_CREATED="$TS_OUTDIR/${TS_TESTNAME}-cramfs.img" #Image created during the test and compared against the known images.
+umask_saved=$(umask)
umask 133
test_image() {
# sudo may use whatever group
chgrp -R 0 $IMAGE_DATA
+umask "$umask_saved"
+
#perform tests for both endians
test_image "little"
test_image "big"