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
