generic/398: Accept failing with EPERM in addition to ENOKEY for rename without key

Some filesystems (e.g. UBIFS) fail with EPERM when trying to move a
file into an encrypted directory via cross rename, without having
access to the encryption key.

Since rename is perfectly allowed to return EPERM, which is also
tested for, and no precise specification seems to exist that
clarifies when to expect EPERM and when ENOKEY, this patch modifies
the generic/398 test to accept both, for the test case where the key
is not available.

Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This commit is contained in:
David Oberhollenzer
2017-06-07 10:20:46 +02:00
committed by Eryu Guan
parent cc34c5f81f
commit 62de87749a
2 changed files with 10 additions and 4 deletions
+8 -2
View File
@@ -43,6 +43,12 @@ _cleanup()
rm -f $tmp.*
}
filter_enokey()
{
# rename without key can also fail with EPERM instead of ENOKEY
sed -e "s/Required key not available/Operation not permitted/g"
}
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
@@ -149,9 +155,9 @@ efile1=$(find $edir1 -type f)
efile2=$(find $edir2 -type f)
echo -e "\n\n*** Exchange encrypted <=> encrypted without key ***"
src/renameat2 -x $efile1 $efile2
src/renameat2 -x $efile1 $efile2 |& filter_enokey
echo -e "\n*** Exchange encrypted <=> unencrypted without key ***"
src/renameat2 -x $efile1 $udir/ufile
src/renameat2 -x $efile1 $udir/ufile |& filter_enokey
# success, all done
status=0
+2 -2
View File
@@ -39,7 +39,7 @@ Operation not permitted
*** Exchange encrypted <=> encrypted without key ***
Required key not available
Operation not permitted
*** Exchange encrypted <=> unencrypted without key ***
Required key not available
Operation not permitted