Hi,
On Tue, Oct 24, 2000 at 02:03:51PM +0200, Christoph Hellwig wrote:
> IMHO the EA stuff should be mostly used as backing-store for other APIs.
Agreed, partially.
For things like DMAPI (XDSM), we have a high-level API which wants to
store arbitrary information in the filesystem. The kernel doesn't
have to parse that info --- it just makes it available to the upper
API. That's an ideal candidate for ATR_SYSTEM extended attributes.
> Shure there should be lowlevel access to the eas for user-EAs or some
> special cases, but for the main usages (ACLs, Filesystem Capabilities,
> MACs) there should be a special high-level API instead.
> So instead of using the EA-API for your ACL lib und progs, you use ACL
> syscalls instead. Theses map to EAs as specified in the ACL kernel module.
I don't understand. This is exactly why I specified that there be an
ATR_POSIXACL attribute family. That family *is* a high level
interface to ACLs. The whole point of the API was to avoid having to
use the low-level attribute functions when dealing with complex
objects like ACLs!
If the underlying implementation in the filesystem wants to use its
normal attribute mechanism to store the ACLs, then that's fine, but we
*CANNOT* force them to do so (especially on distributed filesystems
like NFSv4 or AFS, in which the client simply does not have ANY access
to the underlying ACL mechanics).
The whole point of the proposal was to allow us to have the extended
attribute and the ACL functionality clearly separated, but still
presented in a uniform API. The ACL API *has* to be done in some form
of extensible way anyway, because different existing filesystems have
different semantics and different sets of ACL entry types. The
attribute family ATR_POSIXACL is a generic ACL API for any filesystem
that enforces POSIX ACLs, but other filesystems may want a different
attribute family: ATR_AFSACL, for example, would work in terms of
Kerberos tokens instead of Unix IDs, and would offer a different set
of permissions bits.
Or am I missing something? I don't see why the proposed API doesn't
provide exactly the sort of high-level ACL API you want.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
