Hi,
On Wed, Oct 25, 2000 at 03:03:59AM +0200, Andreas Gruenbacher wrote:
> On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
>
> > 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.
So how do we deal with an existing filesystem which allows user
attributes to be prefixed with "." or "$"? Or which allows arbitrary
other prefixes? Or which allows "." in the middle of attribute names?
Or how do we deal with filesystems whose namespace for attributes is a
binary integer? (Yes, they exist.)
Also, your API doesn't let us set multiple EAs at once, or to do an
atomic set-and-get.
Thirdly, it doesn't deal with extension --- what if I want to add a
new type of attribute? Say, MAC labels or file flags (eg. ext2
"chattr" flags)? With the fsetattr() API, you can define new
attribute families very easily without losing the advantages of a
properly typed API. You can do atomic updates and get-and-set on the
MAC labels. You can set the attributes on a block device inode
without opening it (finally!, a way to fix the current bug which
prevents us modifying file flags on special inodes --- the current
ioctl method is a hack which doesn't work on them since special inodes
redirect ioctls to the device or socket back end.)
> > 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?
Umm, maybe because the original design goal was to make ACLs and it
was easier to add in null application ACEs while they were at it than
to make a separate infrastructure for EAs?
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.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
