lkml.org 
[lkml]   [2023]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A pass-through support for NFSv4 style ACL
    On Wed, May 17, 2023 at 09:42:59AM +0200, Christian Brauner wrote:
    >
    > I have no idea about the original flame war that ended RichACLs in
    > additition to having no clear clue what RichACLs are supposed to
    > achieve. My current knowledge extends to "Christoph didn't like them".

    As to what RichACL's are supposed to achieve....

    Windows/NFSv4 -style ACL's are very different from POSIX semantics, in
    a gazillion ways. For example, if you set a top-level acl, it will
    automatically affect all of the ACL's in the subhierarcy. This is
    trivially easy in Windows given that apparently ACL's are evaluated by
    path every time you try to operate on a file (or at least, that's how
    it works effectively; having not taken a look at Windows source code,
    I can't vouch for how it is actually implemented.) This is, of
    course, a performance disaster and doesn't work all that well for
    Linux where we can do things like like fchdir() and use O_PATH file
    descriptors and *at() system calls. Moreover, Windows doesn't have
    things like the mode parameter to open(2) and mkdir(2) system calls.

    As a result, RichACL's are quite a bit more complicated than Posix
    ACL's or the Windows-style ACL's from which they were derived because
    they have to compromise between the Windows authorization model and
    the Posix/Linux authorization model while being expressive enough
    to mostly emulate Windows-style ACL's. For example, instead of
    implementing Windows-style "automatic inheritance", setrichacl(1) will
    do the moral equivalent of chmod -R, and then add a lot of hair in the
    form of "file_inherit, dir_inherit, no_propagate, and inherit_only"
    flags to each ACL entry, which are all there to try to mostly (but not
    completely) handle make Windows-style and Linux/POSIX acl's work
    within the same file system. There's a lot more detail of the hair
    documented here[1].

    [1] https://www.systutorials.com/docs/linux/man/7-richacl/

    I'll note most of this complexity is only necessary if you want to
    have local file access to the file system work with similar semantics
    as what would get exported via NFSv4. If you didn't, you could just
    store the Windows-style ACL in an xattr and just let it be set via the
    remote file system, and return it when the remote file system queries
    it. The problem comes when you want to have "RichACLs" actually
    influence the local Linux permissions check.

    Personally, I think this is rarely needed, since (a) most people
    implementing a Windows-style filer for Windows client are doing so on
    a dedicated file server, and local access to the exported files are
    rarely needed. Secondly, (b) Windows-style access need to be
    expressed in terms of Windows-style Security ID's for large complex
    enterprise deployment where you have nested Windows-style domains, and
    how you map a 128+ bit Windows SID to a local Unix UID is a previously
    unsolved problem.

    So it's a pretty rare niche use case, and *I've* never thought that
    this is all that important. On the other hand, for those people who
    believe that "This is the year of the Linux Desktop", and who might
    want to export their local Linux directories on their Desktop to a set
    of peer Windows clients, and who are using complex Windows-style ACL's
    (but not *too* complex such that they have nested domain identifiers),
    then RichACL's might be just the ticket. Furthermore, RichACL's are
    apparently an out-of-tree patch maintained by some distros in their
    distro kernel, so maybe they know something I don't.

    Add to that the issues of the implementation level concerns which
    Cristoph has already described, and it's really not all that
    surprising that the progress on the patchset kind of stalled....

    - Ted

    \
     
     \ /
      Last update: 2023-05-17 14:40    [W:2.079 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site