lkml.org 
[lkml]   [2015]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v15 00/22] Richacls (Core and Ext4)
    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 (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.

    In the meantime, I don't mind the approach of staging this in via a
    pseudo-xattr, Samba can deal with that (and it will make some of the
    backup and data movement tools easier for the cifs.ko client which
    currently rely on a cifs specific xattr).

    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:01    [W:3.504 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site