Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data

[Eric Biggers <ebiggers@kernel.org>]

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