Re: fs/crypt ioctl and attr

[Eric Biggers <ebiggers@google.com>]

Hi Anand,

On Tue, Feb 07, 2017 at 07:19:00AM +0800, Anand Jain wrote:
> 
> Hello,
> 
>  As I understand the usage of
> 
>     EXT4_IOC_SET(GET)_ENCRYPTION_POLICY
> 
>  and as the policy is set per inode and stored as an attribute,
>  any reason that - it should be a selinux attribute in specific ?
>  and setfattr / getfattr wasn't used instead of the above ioctl ?
> 
>  IMO, if its attribute its better to have it read/writable
>  using the generic tools such as set(get)fattr. ?
> 
> Thanks, Anand

The xattr which stores the fscrypt_context, which is the on-disk equivalent of a
fscrypt_policy, is not exposed through the extended attributes syscalls such as
getxattr() and setxattr().  This is by design, for various reasons.

First, there are specific rules around when and how userspace may enable
encryption.  For example, encryption can only be enabled on an empty directory,
it's not supported to "unencrypt" an encrypted file or directory in-place,
filesystems may require setting an inode flag when the fscrypt_context is
created, filesystems may require that a superblock flag has been enabled first,
and only specific encryption modes and flags are currently supported and
therefore other ones should be rejected.

Also, it's helpful to decouple the structure passed into the API from the
on-disk representation, for various reasons but currently mainly because the
on-disk xattr includes a nonce, which is generated by the filesystem using
get_random_bytes().  It's not a good idea to force userspace to generate the
nonce because then every program using the API has to get it right, instead of
just the filesystem.

Eric