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

[Marius Bendiksen]

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

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

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.

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

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

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

Yours,
Marius

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