Re: [PATCH v11 21/48] ext4: Add richacl feature flag

Austin S Hemmelgarn
2015-10-16T17:31:44Z

[-- Attachment #1.1: Type: text/plain, Size: 2222 bytes --]

On 2015-10-16 11:17, Andreas Gruenbacher wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This feature flag selects richacl instead of posix acl support on the
> file system. In addition, the "acl" mount option is needed for enabling
> either of the two kinds of acls.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/ext4/ext4.h | 6 ++++--
> fs/ext4/super.c | 42 +++++++++++++++++++++++++++++++++---------
> 2 files changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index fd1f28b..b97a3b1 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -991,7 +991,7 @@ struct ext4_inode_info {
> #define EXT4_MOUNT_UPDATE_JOURNAL 0x01000 /* Update the journal format */
> #define EXT4_MOUNT_NO_UID32 0x02000 /* Disable 32-bit UIDs */
> #define EXT4_MOUNT_XATTR_USER 0x04000 /* Extended user attributes */
> -#define EXT4_MOUNT_POSIX_ACL 0x08000 /* POSIX Access Control Lists */
> +#define EXT4_MOUNT_ACL 0x08000 /* Access Control Lists */
> #define EXT4_MOUNT_NO_AUTO_DA_ALLOC 0x10000 /* No auto delalloc mapping */
> #define EXT4_MOUNT_BARRIER 0x20000 /* Use block barriers */
> #define EXT4_MOUNT_QUOTA 0x80000 /* Some quota option set */
> @@ -1582,6 +1582,7 @@ static inline int ext4_encrypted_inode(struct inode *inode)
> #define EXT4_FEATURE_INCOMPAT_LARGEDIR 0x4000 /* >2GB or 3-lvl htree */
> #define EXT4_FEATURE_INCOMPAT_INLINE_DATA 0x8000 /* data in inode */
> #define EXT4_FEATURE_INCOMPAT_ENCRYPT 0x10000
> +#define EXT4_FEATURE_INCOMPAT_RICHACL 0x20000
I would like to re-iterate, on both XFS and ext4, I _really_ think this
should be a ro_compat flag, and not an incompat one. If a person has
the ability to mount the FS (even if it's a read-only mount), then they
by definition have read access to the file or partition that the
filesystem is contained in, which means that any ACL's stored on the
filesystem are functionally irrelevant, and making this an incompat
feature will just complicate things further for people who have a
legitimate need to recover data.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]