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

[Marius Bendiksen]

First off, I would apologize for the harsh wording I have displayed so
far, and may display throughout this mail. Please bear with me, and do
not take offence, for none is intended.

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

Let's start with the two most obvious ones.

(a) Users shouldn't deal with system attributes directly.
    - MSDOSFS provides non-POSIX attributes that will be reflected as EAs
    - Root may want to script EA updates or EA based work
(b) Special attention will be merited.
    - Not necessarily given.

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

Which gives yet another crippled approach, as attributes might begin with
[0-9_] under certain systems.

> You're saying here that buffer space is a non-issue. I disagree. You're

No. Buffer space is an issue. But it does not concern this aspect. You can
easily avoid consuming more buffer space by preprocessing the EA name.
This does not have a significant added cost.

> not only setting and retrieving single attributes, but also querying lists
> of attribute names. For that operation space matters.

Yes, but this space will likely be consumed rapidly, and freed rapidly,
thus not really impacting buffer space at all. Further, you would want a
flag to indicate whether specific spaces should be returned, or all of
them. That resolves the problem for most non-transient consumption. In
the worst case, increasing the free memory threshold _slightly_ will
rid you of the remainder of the problem.

> 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 would argue that such would need to be done in a library if so. But I
would agree that this is a viable approach. This is much the same as I
argued related to general name translation.

What it adds is the ability to add new families of extended attributes.
The user/system distinction may in time end up as being as inadequate as
the distinction between regular/super user ended up being for security.

And I do not consider "unnecessary right now" to be any argument as to
the design of the EA interface, as it really is saying "I do not think
that we will need to design this interface for the future". Which I'd,
less humbly than usual, say is patently false.

We hold here a _great_ opportunity to introduce a mechanism that could
well be the closest thing to a be-all/end-all of extensions to objects
in the file system we'll see for a long time. Let us think of it as if
this is the case, not as if we're merely catering to our own _current_
needs. Otherwise, mark my words, this will come back to bite us.

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

I will cede this point, even though I think the space would be consumed in
a sufficiently transient manner that it makes no difference.

> 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

Er. I have replied to those reasons, and in fact a number of other issues.
If you have further replied to that, my mailbox must be dropping stuff on
my floor.

> fault tolerance (like a single disk block failure).

When did this become our task to cater for? If such is considered an issue
at all, then I suggest we simply add a parity function. And a single disk
block failure would not cause more damage than the loss of the root
directory inode and/or the block it resides in. SPoF is a RAID issue, IMO.

> 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 upper limit on the number of characters in the FreeBSD VFS is on the
order of billions, if they haven't yet switched to 64 bit size_t's. This
limit is a hardware limit which makes sense right now and forever. Certain
filesystems allow 8+3, some allow 14, some 16, some 256, some more.

6 character identifiers in C also used to be a limit that made sense.

What I am arguing, is that the implementation is free to reject a name,
based on not being able to handle it. However, the design should not
be enforcing short names. I consider 64 characters to be the absolute
minimum length we should support, and that is not counting a prefix.

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

What I meant, is, that you will be eating up the "cap" attribute, which
could be mapped to the native capabilities of certain filesystems. We're
discussing POSIX.1e, we should assign names like:
   system.posix1e.capabilities

This makes for a cleaner layout, and should be done right from the start,
rather than hacking as we go.

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

Not for me, in MyFS. Not for OS/2 in HPFS. And doubtless not for JFS or
XFS, I should think. So why should we _make_ it into a problem at a design
level?

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

OS/2 stores these long names on disk, in a B+ tree structure attached to
the inode. No translation, except as mandated by local character sets,
will be performed.

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

I would prefer to leave the specifics of this to the implementors. Let's
seperate the design from the implementation here. What the _design_ should
allow, and what the _API_ presented to users should allow, is to have
names of at least 64 characters in length, preferrably at least 100. How
this is mapped to any particular filesystem, I care not.

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

Yes. But extensions to the single-character approach are more limited,
less clean, and more likely to turn into hacks as time passes.

Allow me to repeat that none of this is meant as an attack or offense; I
merely find myself unable to write as neutrally as I would have prefered
today, yet this is a critical topic.

Please disregard my wording, but not the concepts.

Marius

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