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