lkml.org 
[lkml]   [2015]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v15 00/22] Richacls (Core and Ext4)
On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote:
> On Tue, Nov 10, 2015 at 6:39 AM, Andreas Gruenbacher
> <agruenba@redhat.com> wrote:
> > On Tue, Nov 10, 2015 at 12:29 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >> On Mon, Nov 09, 2015 at 12:08:41PM +0100, Andreas Gruenbacher wrote:
> >>> Here is another update to the richacl patch queue. This posting contains
> >>> the patches ready to be merged; the patches later in the queue still need
> >>> some more review.
> <snip>
> >> and still abuses xattrs instead of a proper syscall interface.
> >> That's far from being ready to merge.
> >
> > The xattr syscall interface is what's used for very similar kinds of
> > things today; using it for richacls as well sure does not count as
> > abuse. Things could be improved in the xattr interface and in its
> > implementation, but we need more substantial reasons than that for
> > reimplementing the wheel once again.
>
> I don't have strong disagreement with using pseudo-xattrs to
> store/retrieve ACLs (we already do this) but retrieving/setting an ACL
> all at once can be awkward when ACLs are quite large e.g. when it
> encodes to over 1MB

At least in the NFS case, that's also a limitation of the protocol. If
we really wanted to support massive ACLs then we'd need both syscall and
NFS interfaces to allow incrementally reading and writing ACLs, and I
don't even know what those would look like.

So this is a fine limitation as far as I'm concerned.

> (not all administrators think about the size of
> ACLs when they add hundreds of users or groups or apps to ACLs).
>
> The bigger problem is that when ACLs are created -- after -- the file
> is created there is a potential race (harder to deal with in cluster
> and network file systems). Ideally we should be able to optionally
> pass all the security information needed to create a file in the
> create call itself. For apps which don't care they can continue to
> use the old syscalls.

That would be most of them, I'd think.

But I suppose windows apps (via Samba or Wine?) could use this.

Definitely a project for another day, in any case.

--b.

> In cifs.ko I still need to enable the SMB3 ACL helper functions
> (currently only enabled for the older cifs dialect) since that will
> make it easier, and figure out a way to allow helper tools to view
> "claims based ACLs" (DAC), not just traditional
> CIFS/NTFS/SMB3/RichACLs.
> --
> Thanks,
>
> Steve


\
 
 \ /
  Last update: 2015-11-10 18:21    [W:0.095 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site