All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	agruen@kernel.org, akpm@linux-foundation.org,
	viro@zeniv.linux.org.uk, dhowells@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V8 00/26]  New ACL format for better NFSv4 acl interoperability
Date: Mon, 24 Oct 2011 07:07:59 -0400	[thread overview]
Message-ID: <20111024110759.GA1863@fieldses.org> (raw)
In-Reply-To: <20111024094910.GA28693@infradead.org>

On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> > 
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
> 
> It really has to through the VFS tree.

Do we have a VFS tree right now?

> And to be honest despite the repostings there's been exactly zero
> progress on getting there.

Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?

> Please as a first thing submit the various small cleanups indepent
> of the other changes.  If you can't even those in there's no point
> in trying.  Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems.  Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done.  For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one.  And please
> wire up all common filesystems to actually prove that point.

Sounds reasonable.

> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated.  Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up.  There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).

Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right?  (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)

> After all this techical work (which was brought up before) has been
> done you can resubmit it.  And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.

It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.

I don't know how to make the justification much longer than that.

--b.

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: "Aneesh Kumar K.V"
	<aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	agruen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
	dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH -V8 00/26]  New ACL format for better NFSv4 acl interoperability
Date: Mon, 24 Oct 2011 07:07:59 -0400	[thread overview]
Message-ID: <20111024110759.GA1863@fieldses.org> (raw)
In-Reply-To: <20111024094910.GA28693-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> > 
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
> 
> It really has to through the VFS tree.

Do we have a VFS tree right now?

> And to be honest despite the repostings there's been exactly zero
> progress on getting there.

Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?

> Please as a first thing submit the various small cleanups indepent
> of the other changes.  If you can't even those in there's no point
> in trying.  Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems.  Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done.  For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one.  And please
> wire up all common filesystems to actually prove that point.

Sounds reasonable.

> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated.  Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up.  There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).

Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right?  (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)

> After all this techical work (which was brought up before) has been
> done you can resubmit it.  And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.

It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.

I don't know how to make the justification much longer than that.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-10-24 11:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-23 17:43 [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 01/26] vfs: Indicate that the permission functions take all the MAY_* flags Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 02/26] vfs: Add hex format for MAY_* flag values Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 03/26] vfs: Pass all mask flags down to iop->check_acl Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 04/26] vfs: Add a comment to inode_permission() Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 05/26] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 06/26] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 07/26] vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 08/26] vfs: Add new file and directory create permission flags Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 09/26] vfs: Add delete child and delete self " Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 10/26] vfs: Make the inode passed to inode_change_ok non-const Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 11/26] vfs: Add permission flags for setting file attributes Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 12/26] vfs: Make acl_permission_check() work for richacls Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 13/26] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 14/26] richacl: Permission mapping functions Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 15/26] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 16/26] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 17/26] richacl: Permission check algorithm Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 18/26] richacl: Create-time inheritance Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 19/26] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 20/26] richacl: Automatic Inheritance Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 21/26] richacl: xattr mapping functions Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 22/26] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 23/26] vfs: Add richacl permission check Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 24/26] ext4: Use IS_POSIXACL() to check for POSIX ACL support Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 25/26] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2011-10-23 17:43 ` [PATCH -V8 26/26] ext4: Add Ext4 compat richacl feature flag Aneesh Kumar K.V
2011-10-24  9:17 ` [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability J. Bruce Fields
2011-10-24  9:17   ` J. Bruce Fields
2011-10-24  9:49   ` Christoph Hellwig
2011-10-24  9:49     ` Christoph Hellwig
2011-10-24 11:07     ` J. Bruce Fields [this message]
2011-10-24 11:07       ` J. Bruce Fields
2011-10-25 13:30       ` J. Bruce Fields
2011-10-25 13:30         ` J. Bruce Fields
2011-10-24 11:35     ` Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111024110759.GA1863@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=agruen@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.