Closed FruityWelsh closed 1 year ago
The limitation here is mostly just a reflection of the underlying kernel API. FS_IOC_SET_ENCRYPTION_POLICY can only apply a new policy to an empty directory. Thus, this userspace tool has the same restriction.
This is almost always what you want though, because just having filesystem-level encryption on an individual file would not encrypt the filename, and we want things to be secure by default. You can move an individual encrypted file out of an encrypted directory, but then fscrypt unlock
will no longer work.
The primary one I can think of is
.fscrypt
directory, though my first though is allowed for the use of xattrs for those instead.
This might be a misunderstanding of how the /.fscrypt
directory works. That directory is for storing policies/protectors for the filesystem not for a specific directory. The location of the data in that directory will not affect if fscrypt can work on an individual file.
@josephlr I definitely get wanting to encrypt the filename as well as the data, but that would seem reasonably hidden if the directory was encrypted. So in the case in which the filename is not sensitive info the dir could be unencrypted, but the contents of the file would be.
Yes, that was my hopeful misunderstanding on what the .fscrypt file did, thank you for clearing that up too!
That said, thank you for the info and agreed it seems the issue is at the kernel API first
It probably would be possible for the kernel to be changed to allow setting an encryption policy on an empty regular file, but there's been no good reason to allow it so far.
If you really want to, you can already create an encrypted directory and a file within it, then move that file into an unencrypted directory. In that case, you do in fact end up with a standalone encrypted file.
However, as @josephlr mentioned, an issue with standalone encrypted files is that fscrypt unlock
doesn't work. That's because in order to figure out which encryption policy to unlock, it's necessary to open the file to query its encryption policy. But the kernel does not allow encrypted regular files to be opened without their encryption key being present; only directories can be.
Are there any technical limitations that would prevent fscrypt to be applied on a per-file basis instead of a per-directory basis?
The primary one I can think of is
.fscrypt
directory, though my first though is allowed for the use of xattrs for those instead.