linux-kernel - Re: [PATCH -V5 00/24] New ACL format for better NFSv4 acl interoperability

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]

Message-ID: <87pqq5a1qj.fsf@linux.vnet.ibm.com>
Date:	Sat, 05 Mar 2011 23:28:12 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	"Ted Ts'o" <tytso@....edu>, sfrench@...ibm.com, agruen@...bit.com,
	dilger.kernel@...ger.ca, sandeen@...hat.com, jlayton@...hat.com,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V5 00/24]  New ACL format for better NFSv4 acl interoperability

On Fri, 4 Mar 2011 19:32:15 -0500, "J. Bruce Fields" <bfields@...ldses.org> wrote:
> On Fri, Mar 04, 2011 at 04:08:15PM +0530, Aneesh Kumar K. V wrote:
> > On Wed, 2 Mar 2011 13:58:47 -0500, "J. Bruce Fields" <bfields@...ldses.org> wrote:
> > > On Wed, Mar 02, 2011 at 11:17:56PM +0530, Aneesh Kumar K. V wrote:
> > > > On Wed, 2 Mar 2011 10:49:43 -0500, "J. Bruce Fields" <bfields@...ldses.org> wrote:
> > > > > On Tue, Mar 01, 2011 at 12:20:36PM +0530, Aneesh Kumar K. V wrote:
> > > > > > On Mon, 28 Feb 2011 16:11:45 -0500, "Ted Ts'o" <tytso@....edu> wrote:
> > > > > > > Hi Aneesh,
> > > > > > > 
> > > > > > > What is the current status of this patch series?  I seem to remember
> > > > > > > that Christoph and Al Viro had some objections; have those been
> > > > > > > cleared yet?  If not, can you summarize what their objections are?
> > > > > > 
> > > > > > The main objection raised was the use of may_delete and may_create inode
> > > > > > operations callback. They are gone now and we have MAY_* flags as
> > > > > > favoured by Al Viro.  The new MAY_* flags added are 
> > > > > > 
> > > > > > #define MAY_CREATE_FILE 128
> > > > > > #define MAY_CREATE_DIR 256
> > > > > > #define MAY_DELETE_CHILD 512
> > > > > > #define MAY_DELETE_SELF 1024
> > > > > > #define MAY_TAKE_OWNERSHIP 2048
> > > > > > #define MAY_CHMOD 4096
> > > > > > #define MAY_SET_TIMES 8192
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > To be honest I haven't been paying super close attention to this patch
> > > > > > > series, and I'm curious what needs to happen with it one way or
> > > > > > > another.
> > > > > > > 
> > > > > > 
> > > > > > IMHO we are ready to get first 11 patches upstream in the next merge
> > > > > > window. ie the below set of patches.
> > > > > 
> > > > > Why aren't all of them ready?
> > > > > 
> > > > 
> > > > All except how to enable richacl in local file system is ready. I
> > > > actually floated two ideas in the patch series
> > > > 
> > > > 1) mount option
> > > > 2) Ext4 compat flags.
> > > 
> > > The choice of ACL format is a persistant property of the filesystem, not
> > > of a single mount of the filesystem: for example, people can't try out
> > > richacls for one mount and then decide to revert bacak to posix acls.
> > > 
> > > (Right?)  So I'm assuming we should use the latter--but I don't
> > > understand what ext4 compat flags are.... Is there some disadvantage to
> > > using them?
> > > 
> > 
> > We already have a mount option to enable posix acl (-o acl|noacl). So
> > along the same line should we have -o richacl|norichacl or should we
> > have richacl as a ext4 compat flag EXT4_FEATURE_COMPAT_RICHACL. The
> > compat feature can be enabled via tune2fs for an already created file
> > system. Once the compat feature is enabled a -o acl mount option cause
> > the richacl access check to be enabled. That can also result in
> > mapping the existing posix acl in the file system to richacl and
> > using mapped richacl for access restriction. With compat flag once set
> > we will never be able to mount the file system again to use posix acl
> > access restriction. (We cannot map richacl to posixacl because richacl
> > support advanced access masks)
> 
> Sounds fine to me.  I'm not sure you answered my question.  Is there any
> disadvantage to doing it this way?
> 

Andreas didn't like the compat feature flag patch. I don't remember why
though. Andreas can you comment on why you didn't want the compat
feature flag ?

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/