Extended attribute interfaces

[Andreas Gruenbacher]

James Buster wrote:
> 
> > 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.

The number of system calls involved is another concern (albeit orders
of magnitude less critical than disk seeks). This depends on the
interface chosen.

> 
> > 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.

Currently, that's done in three steps:
- query the space required
- allocate memory
- fetch list of names

> > 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.

There's also a race involved when updating an EA (retrieve - modify -
set) since you can't lock the attribute. One possible solutions is to
use some other mechanism (e.g., a file lock) to implement advisory
locking for atomic user attributes. I don't think we need atomicity for
the POSIX1e system objects.
> 
> > 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.

The buffer size required also depends on the length of attribute names,
not only on their count.

> > 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?

This is one of the advantages cited by SGI (in the attr(1) manual page).
One example would be the ICON attribute. If you can write the file, you
can write the icon.


Regards,
Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message