Re: Implementing POSIX ACLs - was: Re: [PATCH] Revised extended attributes interface

[Stephen C. Tweedie]

Hi,

On Tue, Dec 11, 2001 at 01:30:16PM +0000, Anton Altaparmakov wrote:
> At 11:33 11/12/01, Stephen C. Tweedie wrote:
> >On Tue, Dec 11, 2001 at 12:22:58PM +1100, Timothy Shimmin wrote:
> > > Could this not be catered for independent of the proposed EA interface
> > > for getting/setting/removing EAs ?
> >
> >Definitely.  The whole problem I pointed out with the EA interface was
> >that it didn't talk about ACLs at all.  So, sure, it gives us an API
> >for arbitrary EAs, but it does absolutely nothing to help us unify ACL
> >APIs.
> 
> And this is a Good Thing(TM). EAs are completely orthogonal to ACLs and the 
> API for EAs should not in any way have anything to do with ACLs.

At the moment, however, they do.

The user-visible APIs for ACLs and EAs are quite separate.  However,
the way that the user ACL libraries talk to the filesystem is through
special reserved EAs, to which the kernel magically imparts ACL
semantics.  The format of that EA, its name, its semantics and so on,
are all completely glossed over by the existing EA spec, despite the
fact that this mechanism is right at the very core of the ACL
implementation.

> It is up to a different API to implement ACLs. In the case of xfs, ext3, 
> etc, it can have EAs as a backend to the API but in the case of NTFS ACLs 
> would not be anything to do with EAs.

I know, and that's part of the problem we identified over a year ago.
My old EA proposal had the concept of "attribute families", and
allowed us to define ACL attributes in a completely different
namespace from EAs, so that NTFS, AFS or NFSv4 ACLs could be passed
cleanly through the same API.

> _Please_ do not mix the two issues. We have here a IMO nice API for EAs. 
> Lets get it into the kernel. Once that is done, one can start talking about 
> an API for ACLs.

I'm not mixing them: I'm *trying* to unmix them.

The existing EA code implements magic "handlers" for system EAs.
Undefined magic gets called when you set such an EA.  There's no
mention about this in the spec.

So right now the EA code opens up what is basically a named-ioctl back
door into the filesystems, and ACLs work on top of that.  The existing
ACL and EA code is already enormously intertwined.

> IMHO a generic POSIX ACL API would never even know that ACLs are stored as 
> EAs, this should be up to the individual fs and if several fs use EAs it 
> would make sense to have vfs helpers which all fs can use (a-la generic_* 
> helpers).

Yes, and the existing bestbits ACL API does not have anything like
that abstraction: rather, it relies on doing an assignment to a "$acl"
EA.

So how are we going to do ACLs on top of EAs?  Even if we forget about
the ACL API for now, the API between the ACL layer and the EA layer
*does* matter.  

Cheers,
 Stephen