diff mbox series

[RFC,v3,6/9] tests: adjust generic/429 for extent encryption

Message ID 0952e60c8e73a41a0448e3ada8172744a6882550.1691530000.git.sweettea-kernel@dorminy.me (mailing list archive)
State New, archived
Headers show
Series fstests: add btrfs encryption testing | expand

Commit Message

Sweet Tea Dorminy Aug. 8, 2023, 5:21 p.m. UTC
Extent encryption is different from the existing inode-based encryption
insofar as it only generates encryption keys for data encryption at the
moment at which the data is written. This means that when a session key is
removed, even if there's an open file using it, that file immediately
becomes unreadable and unwritable.

This isn't an issue for non-session keys, which are soft deleted by
fscrypt and stick around until there are no more open files with extent
encryption using them. But for session keys, which are managed by the
kernel keyring directly instead of through fscrypt, when they're removed
they're removed.

generic/429 uses session keys and expects to use the written data after
key removal; while it's not quite what the test means for other
filesystems, most of the test is still meaningful if we push the dirty
data into the filesystem with a sync before dropping the key.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
---
 tests/generic/429 | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Anand Jain Oct. 2, 2023, 11:20 a.m. UTC | #1
On 09/08/2023 01:21, Sweet Tea Dorminy wrote:
> Extent encryption is different from the existing inode-based encryption
> insofar as it only generates encryption keys for data encryption at the
> moment at which the data is written. This means that when a session key is
> removed, even if there's an open file using it, that file immediately
> becomes unreadable and unwritable.
> 
> This isn't an issue for non-session keys, which are soft deleted by
> fscrypt and stick around until there are no more open files with extent
> encryption using them. But for session keys, which are managed by the
> kernel keyring directly instead of through fscrypt, when they're removed
> they're removed.
> 
> generic/429 uses session keys and expects to use the written data after
> key removal; while it's not quite what the test means for other
> filesystems, most of the test is still meaningful if we push the dirty
> data into the filesystem with a sync before dropping the key.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>   tests/generic/429 | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/tests/generic/429 b/tests/generic/429
> index 2cf12316..1d26deda 100755
> --- a/tests/generic/429
> +++ b/tests/generic/429
> @@ -68,6 +68,12 @@ show_directory_with_key()
>   	show_file_contents
>   }
>   
> +# btrfs needs to have dirty data pushed into it before session keyring

> +# is unlinked, as it doesn't set up the data encryption key until then.	


  A whitespace error in this line.



> +if [ "$FSTYP" = "btrfs" ]; then
> +	sync
> +fi
> +
>   # View the directory without the encryption key.  The plaintext names shouldn't
>   # exist, but 'cat' each to verify this, which also should create negative
>   # dentries.  The no-key names are unpredictable by design, but verify that the
diff mbox series

Patch

diff --git a/tests/generic/429 b/tests/generic/429
index 2cf12316..1d26deda 100755
--- a/tests/generic/429
+++ b/tests/generic/429
@@ -68,6 +68,12 @@  show_directory_with_key()
 	show_file_contents
 }
 
+# btrfs needs to have dirty data pushed into it before session keyring
+# is unlinked, as it doesn't set up the data encryption key until then.	
+if [ "$FSTYP" = "btrfs" ]; then
+	sync
+fi
+
 # View the directory without the encryption key.  The plaintext names shouldn't
 # exist, but 'cat' each to verify this, which also should create negative
 # dentries.  The no-key names are unpredictable by design, but verify that the