From: Eric Biggers <ebiggers@kernel.org>
To: fstests@vger.kernel.org
Cc: linux-fscrypt@vger.kernel.org
Subject: [PATCH] generic/398: remove workarounds for wrong error codes
Date: Fri, 30 Oct 2020 22:41:41 -0700 [thread overview]
Message-ID: <20201031054141.695517-1-ebiggers@kernel.org> (raw)
From: Eric Biggers <ebiggers@google.com>
generic/398 contains workarounds to allow for renames of encrypted files
to fail with different error codes. However, these error codes were
fixed up by kernel commits f5e55e777cc9 ("fscrypt: return -EXDEV for
incompatible rename or link into encrypted dir") and 0c1ad5242d4f
("ubifs: switch to fscrypt_prepare_rename()").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
tests/generic/398 | 35 +++++++++--------------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/tests/generic/398 b/tests/generic/398
index fcc6e704..3046c398 100755
--- a/tests/generic/398
+++ b/tests/generic/398
@@ -26,23 +26,6 @@ _cleanup()
rm -f $tmp.*
}
-# The error code for incompatible rename or link into an encrypted directory was
-# changed from EPERM to EXDEV in Linux v5.1, to allow tools like 'mv' to work.
-# See kernel commit f5e55e777cc9 ("fscrypt: return -EXDEV for incompatible
-# rename or link into encrypted dir"). Accept both errors for now.
-filter_eperm_to_exdev()
-{
- sed -e 's/Operation not permitted/Invalid cross-device link/'
-}
-
-# The error code for incompatible cross-rename without the key has been ENOKEY
-# on all filesystems since Linux v4.16. Previously it was EPERM on some
-# filesystems. Accept both errors for now.
-filter_eperm_to_enokey()
-{
- sed -e 's/Operation not permitted/Required key not available/'
-}
-
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
@@ -80,20 +63,20 @@ touch $udir/ufile
# different encryption policy. Should fail with EXDEV.
echo -e "\n*** Link encrypted <= encrypted ***"
-ln $edir1/efile1 $edir2/efile1 |& _filter_scratch | filter_eperm_to_exdev
+ln $edir1/efile1 $edir2/efile1 |& _filter_scratch
echo -e "\n*** Rename encrypted => encrypted ***"
-$here/src/renameat2 $edir1/efile1 $edir2/efile1 |& filter_eperm_to_exdev
+$here/src/renameat2 $edir1/efile1 $edir2/efile1
# Test linking and renaming an unencrypted file into an encrypted directory.
# Should fail with EXDEV.
echo -e "\n\n*** Link unencrypted <= encrypted ***"
-ln $udir/ufile $edir1/ufile |& _filter_scratch | filter_eperm_to_exdev
+ln $udir/ufile $edir1/ufile |& _filter_scratch
echo -e "\n*** Rename unencrypted => encrypted ***"
-$here/src/renameat2 $udir/ufile $edir1/ufile |& filter_eperm_to_exdev
+$here/src/renameat2 $udir/ufile $edir1/ufile
# Test linking and renaming an encrypted file into an unencrypted directory.
@@ -113,13 +96,13 @@ $here/src/renameat2 $udir/efile1 $edir1/efile1 # undo
# rename) operation. Should fail with EXDEV.
echo -e "\n\n*** Exchange encrypted <=> encrypted ***"
-$here/src/renameat2 -x $edir1/efile1 $edir2/efile2 |& filter_eperm_to_exdev
+$here/src/renameat2 -x $edir1/efile1 $edir2/efile2
echo -e "\n*** Exchange unencrypted <=> encrypted ***"
-$here/src/renameat2 -x $udir/ufile $edir1/efile1 |& filter_eperm_to_exdev
+$here/src/renameat2 -x $udir/ufile $edir1/efile1
echo -e "\n*** Exchange encrypted <=> unencrypted ***"
-$here/src/renameat2 -x $edir1/efile1 $udir/ufile |& filter_eperm_to_exdev
+$here/src/renameat2 -x $edir1/efile1 $udir/ufile
# Test a file with a special type, i.e. not regular, directory, or symlink.
@@ -147,9 +130,9 @@ efile1=$(find $edir1 -type f)
efile2=$(find $edir2 -type f)
echo -e "\n\n*** Exchange encrypted <=> encrypted without key ***"
-$here/src/renameat2 -x $efile1 $efile2 |& filter_eperm_to_enokey
+$here/src/renameat2 -x $efile1 $efile2
echo -e "\n*** Exchange encrypted <=> unencrypted without key ***"
-$here/src/renameat2 -x $efile1 $udir/ufile |& filter_eperm_to_enokey
+$here/src/renameat2 -x $efile1 $udir/ufile
# success, all done
status=0
--
2.29.1
reply other threads:[~2020-10-31 5:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201031054141.695517-1-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox