On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
> > Yeah. I think your family-like API doesn't belong in the EA layer but in
> > the high-level ACL layer. This ACL layer would have it's own syscalls,
> > e.g. (very similar to you EA API):
>
> > The EA API would be the one proposed by Andreas:
> >
> > sys_eattr (char * filename, int cmd,
> > const char * name, char * value,
> > size_t size);
>
> But that API is insufficient for EAs. We already have filesystems
> which implement independent system and user namespaces: adopting a
> random new convention like "system attributes start with '$'" is
> incompatible with those, so we can't ever mount an existing XFS (for
> example) filesystem and access its EAs cleanly.
Point taken. I therefore propose to prefix extended user attributes with
another character (say, "."), or alternatively, to use a string prefix,
like "user.mime_type", "system.acl", etc. That should get us rid of such
compatibility issues.
BTW, XFS doesn't implement user+system namespaces. It implements user+root
namespaces. That's something I consider a design fault. The separation
into user + system + trusted makes a lot more sense, particularly in the
face of Posix.1e security extensions.
> [...]
> They are NOT low- and high-level. That's an artificial distinction.
> On some filesystems (such as distributed filesystems), they might be
> *exactly* the same level as far as the local client is concerned, with
> all the other semantics being done on the remote server.
>
> To give you a concrete example, the VMS filesystem has ACLs as the
> low-level API, and EAs as high level ones --- on VMS, extended
> attributes are actually implemented as "Application ACL entries",
> completely turning upside-down your argument that ACLs are built on
> top of EAs!
That sounds like a bad joke. What's the point in naming them like that if
they don't serve to control access at all?
Thanks,
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
