Messages in this thread | | | Date | Mon, 25 Jul 2022 22:13:12 -0400 | Subject | Re: [PATCH RFC 2/4] fscrypt: add flag allowing partially-encrypted directories | From | Sweet Tea Dorminy <> |
| |
>> 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
| |