lkml.org 
[lkml]   [2022]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH RFC 2/4] fscrypt: add flag allowing partially-encrypted directories
From

>> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
>> index 6020b738c3b2..fb48961c46f6 100644
>> --- a/include/linux/fscrypt.h
>> +++ b/include/linux/fscrypt.h
>> @@ -102,6 +102,8 @@ struct fscrypt_nokey_name {
>> * pages for writes and therefore won't need the fscrypt bounce page pool.
>> */
>> #define FS_CFLG_OWN_PAGES (1U << 1)
>> +/* The filesystem allows partially encrypted directories/files. */
>> +#define FS_CFLG_ALLOW_PARTIAL (1U << 2)
>
> I'm very confused about what the semantics of this are. So a directory will be
> able to contain both encrypted and unencrypted filenames? If so, how will it be
> possible to distinguish between them? Or is it just both encrypted and
> unencrypted files (which is actually already possible, in the case where
> encrypted files are moved into an unencrypted directory)? What sort of metadata
> is stored with the parent directory?
Yes, a directory for a filesystem with this flag could have both
encrypted and unencrypted filenames.

When a directory switches to encrypted, the filesystem can get and store
a fscrypt_context for it, as though it were a new directory. All new
filenames for that directory will be encrypted, as will any filename
lookup requests, by fscrypt_prepare_filename() since the directory has a
context.

When a request for a lookup of a name in that directory comes in, it'll
be an encrypted or nokey name; the directory can be searched for both
the encrypted and unencrypted versions of that name. I don't think any
filename collisions can result, as any encrypted filename which happens
to match a plaintext filename will be detected as a collision when it's
first added.

>
> Please note that any new semantics and APIs will need to be documented in
> Documentation/filesystems/fscrypt.rst.
Good point.

Thanks!

Sweet Tea

\
 
 \ /
  Last update: 2022-07-26 04:13    [W:0.085 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site