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

[Aneesh Kumar K. V]

On Mon, 28 Feb 2011 16:11:45 -0500, "Ted Ts'o" <tytso@xxxxxxx> 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.

vfs: Make acl_permission_check() work for richacls
vfs: Add permission flags for setting file attributes
vfs: Make the inode passed to inode_change_ok non-const
vfs: Add delete child and delete self permission flags
vfs: Add new file and directory create permission flags
vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined
vfs: Add IS_RICHACL() test for richacl support
vfs: Add generic IS_ACL() test for acl support
vfs: Add a comment to inode_permission()
vfs: Pass all mask flags down to iop->check_acl
vfs: Indicate that the permission functions take all the MAY_* flags

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