On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote: > > Do you also plan to address d/page cache related issues? > i.e. when two users are logged into the system user rw > is able to see decrypted file names and contents in /home/dags/ > if user dags installs a key and accessed a file. > As far as I know, there are no plans to make it possible for one user to see plaintext while another user sees ciphertext. Fundamentally, the dentry, inode, and page caches are shared systemwide. This cannot be changed by using namespaces; it can only be changed by doing something like an ecryptfs-style stacked mount where the plaintext and ciphertext are actually exposed by different filesystems. And it was a fundamental design goal of ext4 encryption to not do a stacked mount. So the expectation is that to restrict access by other users once a key has been provisioned, file permissions should be used. > Or files in /home/dags/ are still readable even after > user dags purged the key. If you revoke the key (with 'keyctl revoke') rather than unlink the key (with 'keyctl unlink') then it actually does appear to work currently. The difference is that revoking the key is a modification of the key, whereas unlinking the key is only removing a link to the key without affecting any links which the kernel may have internally or which userspace may have in other keyrings. Revocation (but not unlinking) is detected by fscrypt_get_encryption_info() when someone tries to open an encrypted file or directory. There's also a d_revalidate dentry operation which cause a dentry to be invalidated if it's a plaintext name but the directory key is no longer valid, or if it's a ciphertext name but the directory key is now valid. There is however still work needed to make key revocation interact sanely with ongoing filesystem operations. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
