On Thu, Oct 26, 2000 at 04:14:06PM +0100, Stephen C. Tweedie wrote:
> > > Either way, the point stands -- building APIs on assumptions about
> > > implementation details (in this case, that ACLs are built on top of
> > > EAs) is a bad thing.
> > 
> > True enough.
> > 
> > The interface I proposed doesn't enforce the implementation though (I
> > guess I was unclear about this).
> 
> Sure, but it makes an artificial distinction where there isn't one.
> There isn't any difference, really, between ACLs and named attributes
> --- they are just two examples from a whole continuum which includes
> attributes as mundane as filesize through MAC labels, compression
> state, DMAPI attributes and others.  Singling out ACLs for special
> treatment seems bizarre --- my gut feeling is that the API needs to be
> able to deal with other forms of structured attribute in the future
> just as cleanly as it deals with ACLs, so giving ACLs its own special
> syscall seems odd.

I think each system attribute will need it's own API;
* A different API is probably better suitable for the user
this can of course be handled in libc, but in some cases
* different parts of the EA have different security policies

If I understand Andreas correctly, his intention is to store _all_ ACL
data in one EA. The ACL interface will update this one EA with new data;
handling all the ordering and so on. As far as the filesystem is
concerned, the "$ACL" is just another chunk of data it needs to store -
it has no knowledge about what it is. 

In the case of XDSM there is already a set API for the user. For
practical reasons, the userspace-kernel API will also be a XDSM specific
one. All openXDSM need from the filesystem is some way to store opaque
metadata.


I guess I'm saying ACL and EA should be seperate interfaces because the
users should not have to know they are related. In some filesystems
maybe they're not - in others maybe EA is implemented using ACL. The
user doesn't care.


-- 
Ragnar Kj�rstad
Big Storage
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]

Reply via email to