Extended attribute interfaces

[James Buster]

Andreas Gruenbacher wrote:
> I can imagine the following operations on extended attributes:
> get, set (implicit create), remove, enumerate.

Irix has some additional options for extended attributes:

DONTFOLLOW: Do not follow symbolic links when resolving a pathname
CREATE: Return an error (EEXIST) if an attribute of the given name already exists
	on the indicated filesystem object, otherwise create an attribute with the
	given name and value.
REPLACE: Return an error (ENOATTR) if an attribute of the given name does not
	already exist on the indicated filesystem object, otherwise replace the
	existing attribute's value with the given value.

> Speed is important since extended attributes are accessed
> frequently when they are used for ACLs and MAC labels, for
> example. The key issue will be to cut down on the number of
> disk seeks required to fetch extended attributes of a file.

That's a quality of implementation issue. It has nothing to do with the
semantics of the APIs.

> I have implemented and favor the latter approach (copy the list
> of EA names into a buffer).

There needs to be a way of figuring out how many EAs the file has so
you can allocate space for all of them ahead of time.

> Assuming that there will only be a low number of extended
> attributes, fetching a list of attribute names into a buffer is
> faster than opening an enumeration, fetching entries,
> and closing the enumeration.

It would be nice if you can enumerate and fetch atomically (and/or ask for
more than one attribute in a single syscall). That eliminates the race condition
whereby you ask for the list and it changes out from under you when you start
fetching attributes.

> The disadvantage of this interface is that it has a scalability
> problem with large numbers of attributes.

If you have a system limit on total number of attributes per file you can
query with pathconf it shouldn't be a problem. Give it some large starting
value like 256.

> This seems fine for user attributes. I'm not sure whether the
> knowledge that a file is associated with a certain system
> attribute is sensitive information.

It depends upon the security policy. On a system with MAC, all attributes are
sensitive information if you do not satisfy the MAC read policy (or have
CAP_MAC_READ).

> Robert has already mentioned there are two attribute namespaces
> on Irix (user and root). In my Linux implementation, there is a
> user and a system namespace. However, im my implementation the
> only difference between a user EA and a system EA is the
> attribute name: system attributes start with a '$' character,
> while user attribtes start with an English-alphabet character.

As long as there's a way to specify policy on a per-attribute basis
this works fine. getting or setting the $MAC attribute should have a
different security policy than changing the ICON attribute. I note
that you have a per-attribute handler scheme which would seem to handle
this nicely.

> In Irix, user attributes are subject to the same permissions as
> the file/directory they are associated with.

One disadvantage of this scheme is that it allows processes not in the file
owner class to set attributes. Is there a good reason to allow such behavior?

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