[PATCH v4 04/30] fs: add new get acl method

Christian Brauner brauner at kernel.org
Fri Sep 30 13:51:03 UTC 2022


On Fri, Sep 30, 2022 at 03:01:22PM +0200, Miklos Szeredi wrote:
> On Fri, 30 Sept 2022 at 14:49, Christian Brauner <brauner at kernel.org> wrote:
> >
> > On Fri, Sep 30, 2022 at 02:24:33PM +0200, Miklos Szeredi wrote:
> 
> > > Maybe adding the check to ovl_get_acl() is the right way to go, but
> > > I'm a little afraid of a performance regression.  Will look into that.
> >
> > Ok, sounds good. I can probably consolidate the two versions but retain
> > the difference in permission checking or would you prefer I leave them
> > distinct for now?
> 
> No, please consolidate them.  That's a good first step.

Ok, will do.

> 
> > > So this patchset nicely reveals how acl retrieval could be done two
> > > ways, and how overlayfs employed both for different purposes.  But
> > > what would be even nicer if there was just one way to retrieve the acl
> > > and overlayfs and cifs be moved over to that.
> >
> > I think this is a good long term goal to have. We're certainly not done
> > with improving things after this work. Sometimes it just takes a little
> > time to phase out legacy baggage as we all are well aware.
> 
> But then which is legacy?  The old .get_acl() or the new .get_acl()?
> My impression is that it's the new one.   But in that case the big
> renaming patch doesn't make any sense.

Since "legacy" would mean "the older one" it wasn't the best term here.
It'll come down to which one we will be able to remove. I'm exploring
both options. If you want to make the removal of the renaming a hard
requirement for being ok with this series I can reverse the renaming.
(Note that Christoph had requested consistent naming for get and set acl.)



More information about the Linux-security-module-archive mailing list