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

[Anton Altaparmakov]

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.

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.

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

>In effect it is far _too_ extensible: we need to have some agreement on 
>how it can be used if the different ACL applications are to have any hope 
>of working together.

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

If you create a hard connection between ACLs and EAs then you are already 
asserting from the start that there will be file systems with alternate ACL 
interface separate from this "generic" one and alternate user space 
utilities... Perhaps this is what you want, but then it certainly not a 
true generic interface, it's just a "cater for the people who first 
implemented it" interface.

>The bright point is that this can be done reasonably well in user
>space, if we're careful (but we still need to worry about exactly how
>the kernel will deal with validating ACE chains --- we need to specify
>whether EAs in the system namespace are expected to be stored verbatim
>or whether the filesystem is permitted to interpret their semantics
>intelligently.)

At the very least you have to allow for the possibility that a file system 
will have ACLs but those will be NOT EAs. An implementation which actually 
makes this impossible is IMHO unacceptable in the generic parts of the kernel.

IMHO an interface where each fs would have a set of acl_ops which the vfs 
can invoke like inode->acl_ops->{get,set,remove,add,whatever you 
like}_{acl,ace} - you get the idea - is required for a generic 
implementation of POSIX ACLs.

Each fs then implements ACLs any way it likes. xfs,ext3,et al would use the 
EA API, ntfs would use its own security attributes, other fs will do 
whatever is required.

This fits in nicely with the idea for vfs helpers so that xfs,ext3,etc 
could just set their acl_ops to generic_*_acl and be done with it.

Comments?

Best regards,

         Anton