> > ... does it make sense to store an ACL on a file if the access
> > control mechanisms are not enforced? Opinions vary. I've never
> > much worried about it, save for the marshalling questions.
> 
> Can you give me an example of this?  I can think of a few cases where  
> this might be the case, but I'm interested in your specific example.

I don't have one. The discussion on the NFSv4 reflector was years ago.
NFSv4 has a rich set of attributes. Somebody suggested that NFSv4 servers
that don't support some attributes natively could save them opaquely
(blobs). There was a prompt response from others saying, essentially,
no fugazis. I can see both points. Can mtime be saved as a blob?
Not really. It also raises other concerns, like what if setuid=true and
owner=root are saved as blobs?

I think the issue helps illustrate that attributes are not opaque.
The (a) file system actually acts on them and often maintains them.

That said, I don't have a strong opinion about supporting foreign
attributes as blobs at this time.

> NFSv4 fundamentally provides subfiles.  It should then issue subfile  
> operations on the backing volume.  If that fails, it fails.  How else  
> would you expect it to work today on e.g. traditional UFS?

Ya, careful here. The NFSv4 feature is actually called "Named Attributes".
They were motivated, largely, by the SMB and NTFS legacy support of
OS/2 HPFS EAs, which much resemble BSD/Linux EAs. These EAs were not well
understood by us NFS folks. Organically, NFSv4 Named Attributes eventually
turned out to behave like subfiles though the name "attribute" was not
changed. Because Name Attribute content is accessed using ordinary
READ/WRITE operations, subfiles just turned out to be more natural.

I was in on that discussion in 1999. The problem is that an attribute
really needs XDR definition. An opaque named "thingy", whatever its
form, is OK but please don't call it attribute. Hence, I like to say
....ahem..... THERE IS NO SUCH THING AS AN OPAQUE ATTRIBUTE.

Again, nobody I've talked to has seen the legacy EA interfaces in SMB
actually used. I can find no API on NT that manipulates OS/2 EAs. It
just seems to be there in SMB and NTFS for legacy OS/2 clients. Not to
belabor the point but: it seems to me there is a lot of effort going
into BSD/Linux EAs that were tried and deprecated ten years ago in
the other O/S universe.

> Now, if an NFSv4 client wants to use EAs, then it is up to the CLIENT  
> to simulate EAs using some mechanism compatible with the capabilities  
> of NFSv4.  Maybe it chooses to use a special subfile on NFSv4. ...

OK. Let's break down what you just said here.

Let's suppose we have two NetBSD boxes using NFSv4 running
client and server. We'll suppose further that UFS supports
EAs and subfiles.

On the client, an application that uses [gs]etxattr() is going to map
to NFSv4 Named Attribute operations that, for the sake of this
discussion, act on a subfile. If the same application is run on
the server, it calls [gs]etxattr() but, because in "local" mode
they are supported natively, they don't get mapped to subfile
operations. What the client did isn't visible on the server.
Now, when a tar(1) is made on the client I suppose 'x' records
would be used but when made on the server 'E' records would be
used.

Two different file models. That seems quite wrong.

> > Solaris is a UFS file system
> > with considerable deployment and it has no such API. A shadow inode
> > is used to contain FSDs. Two FSDs are defined (that I know of), both
> > are related to POSIX-style ACLs. It is quite extensible and a clever
> > leveraging of existing file system mechanisms (including dump and  
> > fsck).
> > It makes the Solaris UFS extensible. But there are no APIs to directly
> > manipulate an FSD.
> 
> That was a decision on their part, and it's fine.  I see no reason  
> NOT to expose the mechanism, however, to provide a more generic  
> facility.

If you don't see it, that doesn't mean it isn't there. It can be
there and one might still not see it.

What matters is seeing how it would work *CORRECTLY* whether
native or over NFSv4.

> > File attributes should be subject of rigorous definition,
> > including: NFS XDR definitions (marshalling and endianess
> > issues), canonical text (for tar/pax 'x' records), API structures
> > (operands to getxattr()), and perhaps other formal definitions
> > such as XML. They should not be thought of as name/value blobs.
> 
> Balderdash :-)  Perhaps you have an application that would like to  
> tag a file with some additional data that it knows how to  
> interpret... maybe like a content management system... it's private  
> to that application, so why should the file system not treat it as  
> opaque?

Balder balderdash :)
 
> > I'm unclear which way you view "attributes". Formally or as
> > blobs.
> 
> That all depends on who stored the attribute, IMO.

IMO, it ain't an "attribute" unless it is meaningful and
maintained by the file system. Otherwise, it is data. One
mechanism for data suffices: (sub)files.

> > That is a terrific question. It was the subject of quite
> > an exchange on the NFSv4 reflector about three months ago.
> > No conclusion was reached.
> 
> This, to me, is evidence that the NFSv4 "subfiles and nothing else"  
> model is weak.

Please see above on the evolution of NFSv4 Named Attributes.

> Again, to be clear, I have nothing against subfiles.  But I don't  
> think they're a solution to every problem.  I think EAs fill an  
> important need.

To make that statement stick, you would have to make
a case for something EAs do that subfiles don't.

More precisely: something an EA API allows that subfile
APIs do not.

Again, EAs as underpinnings to support things like ACLs are
OK. Lots of ways to skin the representation cat. I don't like
the idea of userland EAs. Hence, I don't like the idea of an API.

> No, I'm not saying that at all.  In fact, they're already in the  
> NetBSD 3.0 API (as are the VOPs, although no file system in NetBSD  
> 3.0 provides the back-end functionality). In -current, we also have  
> the Linux xattr API (which in turn is similar to the 10.4 xattr API;  
> 10.4's is unfortunately different while having the same function  
> names, but I understand why the difference exists).

The Linux getxattr() is the only one that should be supported, IMO.
It isn't an opaque data passer (like read/write). Rather, it is more
like ioctl(). The textual name guides the request, but the underlying
representation is up to the underlying file system.

> -- thorpej

Regards,
	-gww