As of now root[1] can access the plain-text when the data is cached by the user-with-the-key and, root gets error no-key when data is not cached by the user-with-the-key. I think this behavior is a bug if not, wrong design, or looks like I am missing something. [1] for that matter any user who has read access to the files but does not have the keys.
This is an explicit design decision. The main issue is that the VFS and the page cache fundamntally assumes that there is only a single "view" of the state of the files. So once something is cached in the dcache and the page cache, the VFS will happily return it to any user who has permissions. The file system doesn't even get involved.
dcache: yeah its complicated, however I still don't know why file-name was the data-to-protected in the first place. Next, page: a read request by the no-key-user can be checked [1] and returned either ENOKEY or cipher-text using dio. [1] struct inode has crypto_info so it can check the key status and, further more its not at the permission check so no performance impact.
We could try and fix this by adding our own file system unique premissions check, but that slows down every single file open with a keyring search.
not unless file-name encryption is part of the data to be encrypted as above.
It also isn't a complete solution because if you pass the fd around via a unix domain socket, or some such you can still end up with weirdness where whether or not the process which is currently trying to operate on the fd has access to the key (via the rings unique, wild, and wonderful, and nonstandard/non-POSIX keyring access scheme).
Again this is only applicable in the context of file-name encryption.
It also isn't complete, since someone could infer whether or not a file exists, unless we also completely spike out the dcache, which would be an even worse performance disaster.
part of the file-name encryption only problem.
So the current model is that if you want to protect file, the Unix permissions do have to be set correctly, and root can read everything. The presense or absense of keys is *not* currently intended to be an access control mechanism.
yeah encryption is not about the access control itself, I echo that myself often. Factually the problem here is with the file-name encryption (FNE), And, I still don't know the relation between FNE and the Evil Maid attack which, I have been told as the reason for the mandatory FNE for all solutions. Last but not least, the whole purpose of having the encryption metadata to be at the attribute is to facilitate the compatibility with the existing tools rsync -X ; cp --preserve. IMO we have entirely defeated that purpose here. Thanks, Anand
