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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Oct 2015 13:31:26 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Andreas Gruenbacher <agruenba@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Jeff Layton <jlayton@...chiereds.net>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	Dave Chinner <david@...morbit.com>, linux-ext4@...r.kernel.org,
	xfs@....sgi.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, linux-api@...r.kernel.org
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [PATCH v11 21/48] ext4: Add richacl feature flag

On 2015-10-16 11:17, Andreas Gruenbacher wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.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@...ux.vnet.ibm.com>
> Signed-off-by: Andreas Gruenbacher <agruenba@...hat.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.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)