Extended attribute interfaces

[Marius Bendiksen]

First off, I would like to point out that I would very much like to see
extended attributes enumerated, rather than named. A translation mechanism
can then be used instead. This improves speed by increasing node density.
Further, not too many EA names will exist in a typical system, and thus
caching every EA name with a refcount over 1 in wired memory would
alleviate any perceived problem with translation speed.

> extattr_set_file() accepts a path, null-terminate attribute name,
> and scatter-gather iovec of data to set.  As with the VOP, this call
> replaces the current data present.

I would prefer if the attribute name was not null-terminated, as null is a
perfectly valid character in the OS/2 VFS. Thus using an asciiz string
would mean to break HPFS compatibility.

> extattr_get_file() does much the same, except it gets the attribute
> present.

Consider a stat call as well.

> 1) Ability to retrieve list of attributes on a file or directory --
>    presumably something dirent-like, but I'd like to hear about what both
>    the SGI folk and Andreas implemented, as there are many ways to do this
>    (and I have implemented none of them :-).  Retriving is useful for
>    backups (probably only in the application namespace, see below).

OS/2 stores its attributes in a binary tree, which can be listed. This is
very critical, in that OS/2 actively uses extended attributes. Zip and RAR
for OS/2 preserve EAs in the archive. We should be able to do this on Unix
as well (AIX does this already, I think).

A directory style listing, with the ability to stat entries, would be
good, I think. Consider, in this connection, a list of attr_id, attr_body,
pairs. Mappings of attr_id->attr_name can be wired, and attr_body can be a
record index of a sort, allowing sharing of attribute bodies.

> 2) Error value for non-present extended attribute.  Currently I'm using
>    ENOENT, which is blatently confusing and improper :-).  There has been
>    discussion of introducing a new error value, probably EEXTATTR or
>    ENOATTR, both of which seem decent.

If we can get general acceptance for the introduction of new error values,
I am all in favour of this. If not, then ENOENT would appear to be the
closest there is.

> 3) Namespace issues.  The SGI implementation has two namespaces -- root
>    and user.  Properly speaking, I feel it should be "system" and
>    "application", but I like the idea of seperate namespaces to
>    distinguish application use from system use (security labels, for
>    example).  Ted also expressed concerns about exposing application
>    extended attributes to userland, and I agree that there is the
>    potential for some problems here.  Seperate namespaces would allow,
>    say, the Linux community to only permit system attributes and return
>    an error for application ones :-).  That said, the Trusted IRIX
>    programmer's guide suggests a good use of application extended
>    attributes for shared spool directories.  Adding an additional
>    argument for namespace control would make sense.  However, what does
>    this mean for file systems that don't currently have namespaces like
>    that (HPFS, for example).  My feeling is that for backup, also,
>    backup programs should touch only the application namespace, retrieving
>    system namespace stuff through appropriate ACL, capability, etc, APIs.

I think it would be appropriate to introduce new bits to the DACLs.
Currently, we mandate R, W and X, as I recall. I would propose get/set (at
least) bits for system and user attributes. Possibly also others. At the
very least, we need to make provision for mandatory access control here.

Why settle for a broken implementation, when a better one will cost us
only a little more effort to implement?

Marius

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message