On Mon, May 17, 2021 at 04:25:15PM -0700, Omar Sandoval wrote: > > Okay, I think we're in agreement: RWF_ENCODED for the data and separate > ioctls for the encryption context. Since the fscrypt policy struct > includes all of the relevant information, RWF_ENCODED can probably just > have a single ENCODED_IOV_ENCRYPTION_FSCRYPT encryption type. > RWF_ENCODED can express data which is both compressed and encrypted, so > that should be fine as well. > > The only other missing piece that I see (other than filesystem support) > is an FS_IOC_SET_ENCRYPTION_NONCE ioctl. Would such an interface be > reasonable? In theory, it will be possible to add FS_IOC_SET_ENCRYPTION_NONCE. The implementation might be tricky. It would have to take the inode lock, verify that the file is empty, replace the encryption xattr, and re-derive and replace the file's encryption key. Replacing the key should be safe because the file is empty, but it's hard to be sure -- and what about directories? Another concern is that userspace could misuse this ioctl and somehow end up reusing nonces, which would be bad; probably this should be a CAP_SYS_ADMIN thing only. A larger question is whether the goal is to support users backing up and restoring encrypted files without their encryption key being available -- in which case things would become *much* harder. First because of the filenames encryption, and second because we currently don't allow opening files without their encryption key. - Eric
