FUSE extended attribute patches available

Mon Mar 7 07:59:42 UTC 2016

FreeBSD and Linux’s extended-attribute models were inherited from IRIX, as they were introduced to solve the same problems: a place to metadata such as ACLs, MAC labels, capability masks, etc. IRIX had three namespaces: one each for “user”, “root”, and “secure”, reflecting whether or not they were managed by the file owner (or permissions), the privileged root user, or part of the TCB protection mechanism (e.g., for integrity labels).

These extended attributes should not be confused with the filesystem feature of the same name in NFSv4, which is sometimes known by the name “file fork” or “data streams”. EAs in IRIX/FreeBSD/Linux/HPFS/etc are tuple pairs of names and values intended to be written atomically or updated in place specifically for (shortish) metadata such as ACLs, rather than being complete separate data spaces for I/O (e.g., that could be memory mapped).

In FreeBSD’s design, we incorporated the disjoint namespace model, providing USER and SYSTEM, the former being managed by the file owner (and those given suitable permission), and the latter being used for TCB mechanisms such as the implementations of MAC labels, ACLs, etc.

In Linux, they adopted a more free-form mechanism based on a single combined namespace with a prefix — e.g., user.FOO, and system.BAR. Over time it looks like that namespace has been expanded in various filesystem-specific ways. We also have room to expand our namespace, but from the description below, it’s not clear quite what the right mechanism is.

One path would be to introduce a new namespace for filesystem-specific attributes — e.g., EXTATTR_NAMESPACE_FS?

But I think the key question here is whether the existing namespaces can provide the semantics you need. If not, then we likely need a new namespace. But then we get the question as to who controls use of the namespace. Certainly “the filesystem” is one option, but then you will get inconsistency in approaches between filesystems and applications — across various dimensions including protection (who can read/modify them?), allocation (who decides what names should be used for what?), and semantics (what applications can use them, and who backs them up?).

For example: who should be responsible for backing up those attributes? For ‘system’ attributes in FreeBSD, it is assumed that backup tools will be aware of the services layered over the attributes — e.g., that they will back up ACLs using the ACL API, rather than backing up the binary EAs holding the ACLs. For ‘user’ attributes, it is assumed that backup tools (e.g., tar) must explicitly preserve them, since they are user-defined and user-managed. For filesystem-specific attributes, some other choice will need to be made — perhaps filesystem-specific backup tools need to know about them?

Note that in the Linux EA model, ACLs are actually accessed via the EA system calls, whereas in FreeBSD, ACLs are a first-class citizen in the system-call API/ABI, and so user applications don’t treat them as EAs. We made that choice as filesystems may choose themselves not to represent ACLs as EAs, and they have real semantics visible to the VFS layer. In Linux, I believe they chose to pass them via EAs to narrow the system-call interface for filesystem metadata. Both are legitimate choices, but this could also trigger discussions about whether new attributes are best accessed via the EA interface, or new system calls. For filesystem-specific attributes, EAs are likely the better way to go.

Robert

> On 7 Mar 2016, at 07:16, Julian Elischer <julian at FreeBSD.ORG> wrote:
> 
> On 5/03/2016 7:06 PM, Rick Macklem wrote:
>> Ken Merry wrote:
>>> I have patches for FreeBSD’s FUSE filesystem kernel module to support
>>> extended attributes:
> oh showing off your masochistic side eh?
> 
>>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt
>>> 
> I spent an hour beating my head against fuse yesterday.
> then realised that it's an old version on our product. We really have to get off 8.0
> (hopefully a matter of weeks now to a 10.x switch)
> Now all I need is to find  a FreeBSD filesystem expert (ZFS/NFS/CIFS/GFS) to hire.
> 
> 
>> The only bit of code I have that might be useful for this patch is:
>>   	case FUSE_GETXATTR:
>>   	case FUSE_LISTXATTR:
>> ! 		/*
>> ! 		 * These can have varying response lengths, and 0 length
>> ! 		 * isn't necessarily invalid.
>> ! 		 */
>> ! 		err = 0;
>> *** I came up with this:
>> 		fgin = (struct fuse_getxattr_in *)
>> 		    ((char *)ftick->tk_ms_fiov.base +
>> 		     sizeof(struct fuse_in_header));
>> 		if (fgin->size == 0)
>> 			err = (blen == sizeof(struct fuse_getxattr_out)) ? 0 :
>> 			    EINVAL;
>> 		else
>> 			err = (blen <= fgin->size) ? 0 : EINVAL;
>>   		break;
>> I think I got the size check right?
>> 
>> The big question is...
>> What to do with the NAMESPACE?
>> - My code fails for SYSTEM and does USER without prepending "user.".
>>   (That seemed to be what rwatson@ felt was reasonable. I thought our
>>    discussion was on a mailing list, but I can't find it.)
>>   I've cc'd him. Maybe he can comment again.
> Is there  a standard for extended attributes I should knwo about?
> It seems to me that it's a bit like the wild west.
> Extended attributes seem to be "every OS for himself".
> 
>> 
>> - If you stick with prepending "user." or "system." there needs to be
>>   some way to bypass this so that attributes that don't start in "user."
>>   or "system." can be accessed. I've seen "trusted." and "glusterfs."
>>   on GlusterFS.
>>   --> Maybe a new namespace called something like "nil" that just bypasses
>>       any USER or SYSTEM checks?
>> 
>> rick
>> 
>>> The patch implements the get/set/delete/list extended attribute methods.  The
>>> listing code also converts extended attribute lists from the Linux/FUSE
>>> format to the FreeBSD format.  For example:
>>> 
>>> # touch foo
>>> # ls -la foo
>>> -rwxrwxrwx  1 root  wheel  0 Feb 29 21:40 foo
>>> # lsextattr user foo
>>> foo
>>> # setextattr user testattr1 "12345678" foo
>>> # lsextattr user foo
>>> foo     testattr1
>>> # getextattr user testattr1 foo
>>> foo     12345678
>>> # setextattr user testattr2 "87654321" foo
>>> # lsextattr user foo
>>> foo     testattr2       testattr1
>>> # rmextattr user testattr1 foo
>>> # lsextattr user foo
>>> foo     testattr2
>>> # getextattr user testattr1 foo
>>> getextattr: foo: failed: Attribute not found
>>> # getextattr user testattr2 foo
>>> foo     87654321
>>> 
>>> 
>>> Just to be clear on what this does, it only provides extended attribute
>>> support to FreeBSD applications if the underlying FUSE filesystem implements
>>> FUSE extended attribute support.  Many FUSE filesystems don’t support the
>>> extended attribute VFS operations.
>>> 
>>> I have tested this out on IBM’s LTFS implementation, but I have not yet found
>>> another FUSE filesystem that supports extended attributes.  If anyone knows
>>> of one, please let me know so I can try it out.  (I looked through a number
>>> of the filesystems in sysutils/fusefs* in the ports tree.)
>>> 
>>> Any feedback is welcome.  I’m planning to check this into FreeBSD/head in the
>>> next week or so.
>>> 
>>> Obviously, I’ve also ported IBM’s LTFS implementation to FreeBSD.  It works
>>> in the standard FUSE mode, and you can also link it into an application as a
>>> library if you don’t want to incur the overhead of running through FUSE.  I
>>> haven’t gotten around to packaging it up to go out for testing / review.
>>> 
>>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer tape
>>> drives, and wants to try it out, let me know.  I’ll send you the code when
>>> I’ve got it at least somewhat ready.  This is IBM-specific, and won’t work
>>> on HP tape drives.
>>> 
>>> Ken
>>> —
>>> Ken Merry
>>> ken at FreeBSD.ORG
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> freebsd-fs at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>> _______________________________________________
>> freebsd-fs at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>> 
>> 
> 