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

[Andreas Gruenbacher]

On Thu, 21 Sep 2000, Marius Bendiksen wrote:

> > 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.
> 
> This makes assumptions that I, personally, don't like.

Please be more specific. Which assumptions are you objecting to exactly?

> But more
> importantly, it limits us to distinguishing only between two types of
> attributes, user and system. At some point in the future, someone may
> want to extend the EA mechanism with another type, and at this point,
> you do *not* want them to have to use a character which was previously
> non-reserved.
> 
> Let's do this right the first time around.

All initial characters not in [A-Za-z$] are reserved at the moment.

> > 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.
> 
> This is a non-issue. The wise implementor will realize that he (for now)
> needs only a single bit to store the distinction between user and system.
> As system attributes will merit special treatment either way, the
> implementation needs only scan the attribute name and scratch the prefix
> when storing the attribute.

You're saying here that buffer space is a non-issue. I disagree. You're
not only setting and retrieving single attributes, but also querying lists
of attribute names. For that operation space matters.

Sure one could translate prefixes to/from internal names. I have no big
problem with doing this in userspace, should this be the agreed upon, with
additional reasoning what it adds and why that's important. I think it's
unnecessary right now, but I may be convinced otherwise.

I definitely don't want such translations in the kernel.

> Note also that the problem of name length is entirely resolved by using
> the model I suggested some time ago, in a thread which died from lack of
> feedback from someone.

Using a lookup table you mean. I already gave you some reasons why that's
unfavorable. One serious problem introduced by that definitely would be
fault tolerance (like a single disk block failure).

> > 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.
> 
> Let's not cripple the *design* based on difficulties encountered in a
> specific implementation. Realize that this design will need to be the
> backbone for further extensions to most filesystems. This is more than
> some simple hack to get capabilities and ACL in there.

Guess what's the reason for having an upper limit on the number of
characters in a filename? That surely also is an artificial limit that
just happens to make sense in that particular case.

The attribute namespace is flat (no hierarchy). It should be no serious
problem at all to find several hundred short system attribute names should
they be needed. Starting with short names has no implications for future
growth.

Associating several hundred attributes with a single file at the same time
raises some problems, though.

> > 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.
> 
> How do you know that there will always be a limited set? OS/2 has several
> hundred system attributes. These are clearly identified by use of long
> names that can even be presented directly to the user. Do not limit a
> design with the limits upon what uses you can imagine. Some time ago, 640k
> was imagined as being the maximal extent of what people would need. Why
> should we do similar assumptions?

I would assume OS/2 didn't store these long names on disk but used some
translation, probably outside of the kernel.

For attribute name translations, if at all I would first think of another
resource file in /etc that contains translations.

> > So we seem to agree a unified namespace makes sense. I'm pleased about
> > that.
> 
> Unified does not necessarily mean typeless. A segmented model, using
> prefixes, like Robert suggested, would make a lot of sense, without
> discarding the unified namespace approach.

Prefixes and types are completely orthogonal. Both schemes discussed
support the same type.


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