Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 19 May 2023 12:56:55 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Theodore Ts'o <tytso@mit.edu>
Cc:     Jeff Layton <jlayton@kernel.org>,
        Ondrej Valousek <ondrej.valousek.xm@renesas.com>,
        "trondmy@hammerspace.com" <trondmy@hammerspace.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: A pass-through support for NFSv4 style ACL
Message-ID: <20230519-allzu-aufmerksam-c3098b5ecf0d@brauner>
References: <20230516124655.82283-1-jlayton@kernel.org>
 <20230516-notorisch-geblickt-6b591fbd77c1@brauner>
 <TYXPR01MB18549D3A5B0BE777D7F6B284D9799@TYXPR01MB1854.jpnprd01.prod.outlook.com>
 <cc4317d9cb8f10aa0b3750bdb6db8b4e77ff26f8.camel@kernel.org>
 <20230517-herstellen-zitat-21eeccd36558@brauner>
 <20230517123914.GA4578@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230517123914.GA4578@mit.edu>
Precedence: bulk

On Wed, May 17, 2023 at 08:39:14AM -0400, Theodore Ts'o wrote:
> 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....

Interesting, thanks for all the details!

> 
> 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.

Yeah, I'm already scared enough.