Re: [Acl-Devel] Status of ACL patches regarding inclusion in the standard kernel?

[Dave Kleikamp <shaggy@austin.ibm.com>]

On Tuesday 08 October 2002 15:04, Spencer Shepler wrote:
> On Tue, Michael Tokarev wrote:
> > Just a random thought (sorry if it was discussed before) - I don't
> > see why every filesystem with it's own unique layout etc should
> > store ACLs as xattrs - there may be different implementation
> > especially for ACLs but no xattrs at all (at the beginning of the
> > "ACL era", almost everyone agreed that ACL/xattrs subsystem should
> > be more-or-less universal, allowing many different layouts/concepts
> > (think NTFS ACLs vs POSIX ACLs) to be used).  Well, conversion
> > routines may exists (if at all possible), but in some cases this
> > will be an overkill.
>
> This would certainly be true of NFSv4 where ACLs are part of the
> semantically defined attributes and are not part of the xattr space.
> Using [gs]et_posic_acl() would make the translation job
> straightforward for the NFS client/server.

The xattr space is broken down into namespaces that the fs's are free to 
handle any way they wish, so even though the ACL's may come in as an 
xattr, the fs can store it any way it chooses.

This is where I argue that IF we have a separate ACL interface, there's 
no need to require that the xattr interface be used to store the ACL, 
but since most filesystems will use xattrs, we should have a generic 
function that stores/retrieves the ACL in the form of an xattr (and 
caches the ACL for fast access).

If we decide NOT to have a separate ACL interface, the filesystem would 
then deal with the ACL's based on the xattr namespace.  It has the 
freedom to actually store the ACL as an xattr, or in some other 
fashion.  In this case, I still argue for a generic get_posix_acl (not 
a file operation) that calls the fs's get_xattr.  I don't see a need 
for every fs to implement this function.
-- 
David Kleikamp
IBM Linux Technology Center