Privilege level for $ extended attributes? Re: Extended attribute interfaces

[Andreas Gruenbacher]

On Wed, 20 Sep 2000, Robert Watson wrote:

> 
> Andreas,
> 
> Boris and others have raised with me that they are concerned about the
> choice of the symbol '$' as the prefix for system attributes.  In
> particular, because that symbol is widely used as a special character in
> shell scripts and scripting languages.  While they didn't have any
> particular favored recommendations as to an alternative, I can sympathize
> with the concern.  Is this something you feel should not be changed, or
> would you be willing to discuss alternatives?

I still think '$' is a good choice; I was well aware of its meaning in
scripts when choosing it.

Users shouldn't usually deal with system attributes directly---that would
be up to libraries; in scripts one would preferably use standard utilities
(getfacl/setfacl, getfcap/setfcap etc.). When dealing with system
attributes directly the '$' prefix hopefully signals that special
attention is merited.

> One possibility in my mind as been to assume a name-space segmented by the
> "." or "/" characters, and prefix "system." or ".system." in front of the
> attribute name.  Right now, I'm using '$posix1e.cap' for POSIX.1e
> capability backing store, which would result in 'system.posix1e.cap' as
> the new attribute name, which makes a fair amount of sense.  It doesn't
> have the simplicity of allowing the check of a single character, however. 

It also has another drawback. Attribute names get longer. This affects
both on-disk storage space and buffer space for retrieving lists of
attribute names.

Long attribute names are no problem with respect to on-disk space with
your current implementation. With mine that's a pretty serious concern. I
expect you will finally implement some better mechanism for storing
attributes, at which point you may be glad to have short attribute names.

Also I don't see a real need to explicitly tag capabilities as the posix1e
variant. There will always be a very limited set of operating system
objects like that, so a simple '$cap' (and '$acl' etc.) should suffice.
For other more exotic variants (I'm thinking of AFS ACLs for one) there
are still plenty of names left :-)

> In any case, as nothing is set in stone at this point, it's probably a
> good time to discuss the issue.  The SGI solution of simply maintaining
> two namespaces also makes some amount of sense, but a unified namespace
> leads to a unified namespace solution, whereas two namespaces would
> require applications to distinguish between them (such as backup tools)
> themselves, offloading the problem to be solved in numerous different ways
> by different authors.

So we seem to agree a unified namespace makes sense. I'm pleased about
that.


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