Hi Eric,
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, AnandThe 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.
These reasons would equally apply to ioctl interface as well. I don't see this being limiting factor for not using set/getfattr.
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.
Again. I don't see these as the limiting factor for not using set/getfattr. And about the iv/nonce you mentioned, I didn't say to set IV/nonce value from the user land, but it could have been done the same way the attribute inheritance is working now with in the fs/crypto kernel. BTRFS does not have ioctl for the crypto policy set, it did it through xattr, I would like to retain that part even when fs/crypto is used, unless there is any security reason. (But definitely not at the cost of being incompatible with rest of the FSs, I hope to fix that part as well). Here, I am just trying to ensure not to over-do in the name of security. And by letting encryption meta-data easily usable through extended attributes I hope to encourage tools to leverage on the FS encryption. Still my question is unanswered, I was specific to any security or other reasons that set/getfattr interface wasn't used to read/write the policy information. And also why SElinux attributes instead of normal extended attributes. Thanks, Anand
