Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1233752 > unrolled thread

[PATCH v8 00/41] Richacls

Back to article view | Back to linux.kernel

Contents

  [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:10 +0200
    [PATCH v8 31/41] nfsd: Add support for the v4.1 dacl attribute Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 15/41] richacl: Automatic Inheritance Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 03/41] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 12/41] vfs: Cache richacl in struct inode Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 14/41] richacl: Create-time inheritance Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 33/41] richacl: Add support for unmapped identifiers Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 06/41] richacl: In-memory representation and helper functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 09/41] richacl: Update the file masks in chmod() Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
      Re: [PATCH v8 09/41] richacl: Update the file masks in chmod() "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 17:30 +0200
        Re: [PATCH v8 09/41] richacl: Update the file masks in chmod() Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-29 01:50 +0200
    [PATCH v8 13/41] richacl: Check if an acl is equivalent to a file mode Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 27/41] richacl: Create richacl from mode values Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 19/41] ext4: Add richacl feature flag Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 21/41] richacl: Move everyone@ aces down the acl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 20/41] richacl: acl editing helper functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 32/41] nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 26/41] richacl: Apply the file masks to a richacl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 01/41] vfs: Add IS_ACL() and IS_RICHACL() tests Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 41/41] richacl: uapi header split Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 18/41] ext4: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 17/41] vfs: Add richacl permission checking Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 35/41] sunrpc: Allow to demand-allocate pages to encode into Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 38/41] nfs: Remove unused xdr page offsets in getacl/setacl arguments Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 36/41] sunrpc: Add xdr_init_encode_pages Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 16/41] richacl: xattr mapping functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 25/41] richacl: Isolate the owner and group classes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 40/41] nfs: Add support for the v4.1 dacl attribute Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 11/41] vfs: Cache base_acl objects in inodes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 08/41] richacl: Compute maximum file masks from an acl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 34/41] ext4: Don't allow unmapped identifiers in richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 05/41] vfs: Add permission flags for setting file attributes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 28/41] nfsd: Keep list of acls to dispose of in compoundargs Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 04/41] vfs: Make the inode passed to inode_change_ok non-const Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 22/41] richacl: Propagate everyone@ permissions to other aces Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 37/41] nfs: Fix GETATTR bitmap verification Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 29/41] nfsd: Use richacls as internal acl representation Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 39/41] nfs: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
    [PATCH v8 24/41] richacl: Set the other permissions to the other mask Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
    [PATCH v8 23/41] richacl: Set the owner permissions to the owner mask Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
    [PATCH v8 30/41] nfsd: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
    [PATCH v8 07/41] richacl: Permission mapping functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:40 +0200
    [PATCH v8 10/41] richacl: Permission check algorithm Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:40 +0200
      Re: [PATCH v8 10/41] richacl: Permission check algorithm "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:10 +0200
        Re: [PATCH v8 10/41] richacl: Permission check algorithm Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 18:30 +0200
          Re: [PATCH v8 10/41] richacl: Permission check algorithm "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:30 +0200
            Re: [PATCH v8 10/41] richacl: Permission check algorithm Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 19:00 +0200
    [PATCH v8 02/41] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:50 +0200
    Re: [PATCH v8 00/41] Richacls "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:40 +0200
      Re: [PATCH v8 00/41] Richacls Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 19:20 +0200
        Re: [PATCH v8 00/41] Richacls "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 19:50 +0200
          Re: [PATCH v8 00/41] Richacls Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-29 17:00 +0200
            Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-16 20:20 +0200
    Re: [PATCH v8 00/41] Richacls Christoph Hellwig <hch@infradead.org> - 2015-10-04 08:30 +0200
      Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-05 20:50 +0200
        Re: [PATCH v8 00/41] Richacls Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-10-05 21:00 +0200
          Re: [PATCH v8 00/41] Richacls Christoph Hellwig <hch@infradead.org> - 2015-10-06 12:00 +0200
            Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-06 15:20 +0200
              Re: [PATCH v8 00/41] Richacls Andreas Dilger <adilger@dilger.ca> - 2015-10-06 22:30 +0200
                Re: [PATCH v8 00/41] Richacls Steve French <smfrench@gmail.com> - 2015-10-06 23:00 +0200
                Re: [PATCH v8 00/41] Richacls Christoph Hellwig <hch@infradead.org> - 2015-10-07 10:00 +0200
                  Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-07 15:40 +0200
                    Re: [PATCH v8 00/41] Richacls Steve French <smfrench@gmail.com> - 2015-10-07 17:20 +0200
        Re: [PATCH v8 00/41] Richacls Dave Chinner <david@fromorbit.com> - 2015-10-05 23:20 +0200
          Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-06 00:10 +0200
            Re: [PATCH v8 00/41] Richacls Dave Chinner <david@fromorbit.com> - 2015-10-06 03:30 +0200
      Re: [PATCH v8 00/41] Richacls James Morris <jmorris@namei.org> - 2015-10-06 11:50 +0200
        Re: [PATCH v8 00/41] Richacls Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-10-06 14:30 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]

#1241213

On Tue, Oct 06, 2015 at 02:26:09PM -0600, Andreas Dilger wrote:
> And any disk filesystems that have their own non-POSIX ACLs, such as HFS, NTFS, ZFS would presumably also need to map the in-kernel Richacl format to their on-disk format.

No, we did this mistake with Posix ACLs, and we're not going to repeat
it here.  Filesystems with their own slightly different ACLs must not
reuse the interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241498

On Wed, Oct 7, 2015 at 9:50 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Oct 06, 2015 at 02:26:09PM -0600, Andreas Dilger wrote:
>> And any disk filesystems that have their own non-POSIX ACLs, such as HFS, NTFS, ZFS would presumably also need to map the in-kernel Richacl format to their on-disk format.
>
> No, we did this mistake with Posix ACLs, and we're not going to repeat
> it here.  Filesystems with their own slightly different ACLs must not
> reuse the interface.

Well, things may not be quite as clearly delineated. We currently have
code in nfsd for mapping between NFSv4 ACLs on the wire and POSIX ACLs
on local file systems. This mapping is problematic because of the
semantic differences between NFSv4 ACLs and POSIX ACLs (different sets
of permissions, access and default acl vs. inheritance flags,
different permission check algorithm). I wish we could have avoided
that.

Richacls are designed to support NFSv4 ACLs on top of POSIX systems.
This means that they should obviously be supported by the NFSv4 server
and client (see the patches) and by the common local filesystems.

ACLs on NTFS and ZFS mostly fit into the same model. The big remaining
difference there is how users and groups are identified: NTFS used
SIDs (https://en.wikipedia.org/wiki/Security_Identifier); ZFS could be
said to use a hybrid UID / GID / SID model. Exposing those ACLs as
richacls would make sense if we can find a clean way of handling this
aspect.

HFS ACLs have sufficiently different semantics (the user.group tuples)
that representing them as richacls wouldn't make sense.

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

[toc] | [prev] | [next] | [standalone]

#1241589

On Wed, Oct 7, 2015 at 8:38 AM, Andreas Gruenbacher <agruenba@redhat.com> wrote:
> On Wed, Oct 7, 2015 at 9:50 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> On Tue, Oct 06, 2015 at 02:26:09PM -0600, Andreas Dilger wrote:
>>> And any disk filesystems that have their own non-POSIX ACLs, such as HFS, NTFS, ZFS would presumably also need to map the in-kernel Richacl format to their on-disk format.
>>
>> No, we did this mistake with Posix ACLs, and we're not going to repeat
>> it here.  Filesystems with their own slightly different ACLs must not
>> reuse the interface.
>
> Well, things may not be quite as clearly delineated. We currently have
> code in nfsd for mapping between NFSv4 ACLs on the wire and POSIX ACLs
> on local file systems. This mapping is problematic because of the
> semantic differences between NFSv4 ACLs and POSIX ACLs (different sets
> of permissions, access and default acl vs. inheritance flags,
> different permission check algorithm). I wish we could have avoided
> that.
>
> Richacls are designed to support NFSv4 ACLs on top of POSIX systems.
> This means that they should obviously be supported by the NFSv4 server
> and client (see the patches) and by the common local filesystems.
>
> ACLs on NTFS and ZFS mostly fit into the same model. The big remaining
> difference there is how users and groups are identified: NTFS used
> SIDs (https://en.wikipedia.org/wiki/Security_Identifier); ZFS could be
> said to use a hybrid UID / GID / SID model. Exposing those ACLs as
> richacls would make sense if we can find a clean way of handling this
> aspect.

Samba (e.g. winbind service) has mapping libraries for mapping SIDs to
UIDs (CIFS ACLs already have the same issue of SID to UID mapping
which we handle with upcalls) and Samba has various pluggable ways to
handle UID mapping and is easily extensible.  Similarly NFSv4 ACLs,
although closely related to CIFS/NTFS ACLs have to be map usernames to
uids.

-- 
Thanks,

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

[toc] | [prev] | [next] | [standalone]

#1239975

On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote:
> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote:
> >> Hello,
> >>
> >> here's another update of the richacl patch queue.  At this stage, I would
> >> like to ask for final feedback so that the core and ext4 code (patches
> >> 1-19) can be merged in the 4.4 merge window.  The nfsd and nfs code should
> >> then go through the respective maintainer trees.
> >
> > Now way in this form even if everyone agrees we should have these
> > bastard ACLs.  I certainly disagree.
> 
> Well, thanks for having a look at the patches.
> 
> > Ayway, back to the VFS <-> FS interface.  You still require tons of
> > boilderplate code in the filesystem which isn't required and we got rid
> > of for Posix ACLs.  The filesystem should not look at the userspace
> > xattr format, please follow a model similar to ->get_acl and ->set_acl
> > for Posix ACLs.
> 
> I will repost a version that has this cleaned up.
> 
> > After that the wire up should be so trivial that you can wire up btrfs,
> > xfs and f2fs as well, which is important to make the feature mergeable.
> 
> Why would the patch queue become more mergeable by having support for
> more filesystems in it? The filesystem specific code really isn't all
> that interesting.

The hardest part for the filesystem support is the on-disk feature
flag that needs to be set. The kernel part of that is easy, but it's
an on-disk format change and so there's also all the userspace side
for mkfs, fsck, debug tools, etc, that also need to be able to parse
and understand it. So while the xattr code can be made much more
generic, there's a bunch of filesystem specific code that needs to
go into multiple different repositories and userspace packages for
this.

Andreas, I also can't remember if any xfstests have been written for
these ACLs? That would certainly help make sure all these
filesystems have equivalent behaviour...

Cheers,

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

[toc] | [prev] | [next] | [standalone]

#1239994

On Mon, Oct 5, 2015 at 11:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote:
>> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> > After that the wire up should be so trivial that you can wire up btrfs,
>> > xfs and f2fs as well, which is important to make the feature mergeable.
>>
>> Why would the patch queue become more mergeable by having support for
>> more filesystems in it? The filesystem specific code really isn't all
>> that interesting.
>
> The hardest part for the filesystem support is the on-disk feature
> flag that needs to be set. The kernel part of that is easy, but it's
> an on-disk format change and so there's also all the userspace side
> for mkfs, fsck, debug tools, etc, that also need to be able to parse
> and understand it. So while the xattr code can be made much more
> generic, there's a bunch of filesystem specific code that needs to
> go into multiple different repositories and userspace packages for
> this.

Yes.

> Andreas, I also can't remember if any xfstests have been written for
> these ACLs? That would certainly help make sure all these
> filesystems have equivalent behaviour...

There's a reasonable amount of tests in the richacl user-space package
which are shell based, with a few small C helpers. We could move those
into xfstests eventually; now seems a bit early to me.

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

[toc] | [prev] | [next] | [standalone]

#1240104

On Tue, Oct 06, 2015 at 12:01:19AM +0200, Andreas Gruenbacher wrote:
> On Mon, Oct 5, 2015 at 11:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote:
> >> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >> > After that the wire up should be so trivial that you can wire up btrfs,
> >> > xfs and f2fs as well, which is important to make the feature mergeable.
> >>
> >> Why would the patch queue become more mergeable by having support for
> >> more filesystems in it? The filesystem specific code really isn't all
> >> that interesting.
> >
> > The hardest part for the filesystem support is the on-disk feature
> > flag that needs to be set. The kernel part of that is easy, but it's
> > an on-disk format change and so there's also all the userspace side
> > for mkfs, fsck, debug tools, etc, that also need to be able to parse
> > and understand it. So while the xattr code can be made much more
> > generic, there's a bunch of filesystem specific code that needs to
> > go into multiple different repositories and userspace packages for
> > this.
> 
> Yes.
> 
> > Andreas, I also can't remember if any xfstests have been written for
> > these ACLs? That would certainly help make sure all these
> > filesystems have equivalent behaviour...
> 
> There's a reasonable amount of tests in the richacl user-space package
> which are shell based, with a few small C helpers. We could move those
> into xfstests eventually; now seems a bit early to me.

Well, all the fs developers that will do the userspace work are
already running xfstests. If you want us to be able to test the
richACL code as we add all the fs specific flags to the userspace
code, then we need the tests in xfstests at the same time the
infrastructure appears in the kernel...

Cheers,

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

[toc] | [prev] | [next] | [standalone]

#1240324

On Sat, 3 Oct 2015, Christoph Hellwig wrote:

> On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote:
> > Hello,
> > 
> > here's another update of the richacl patch queue.  At this stage, I would
> > like to ask for final feedback so that the core and ext4 code (patches
> > 1-19) can be merged in the 4.4 merge window.  The nfsd and nfs code should
> > then go through the respective maintainer trees.
> 
> Now way in this form even if everyone agrees we should have these
> bastard ACLs.  I certainly disagree.
> 

Where is the rationale for them?

This url doesn't work: http://acl.bestbits.at/richacl/





-- 
James Morris
<jmorris@namei.org>

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

[toc] | [prev] | [next] | [standalone]

#1240412

2015-10-06 11:49 GMT+02:00 James Morris <jmorris@namei.org>:
> Where is the rationale for them?
>
> This url doesn't work: http://acl.bestbits.at/richacl/

That URL also properly redirects to http://www.bestbits.at/richacl/
now. There is some information on that website, in the manual pages in
the richacl user-space package, an in the patch descriptions and
comments.

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

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | linux.kernel

csiph-web