FUSE extended attribute patches available
Robert N. M. Watson
rwatson at freebsd.org
Tue Mar 8 06:38:04 UTC 2016
Just a quick observation: to avoid application change, you could actually leave the 'user.' on the front of the strings? It's not harmful, it just doesn't serve the same function. This might keep documentation more in sync, etc.
Sent from my iPhone
> On 7 Mar 2016, at 22:28, Ken Merry <ken at freebsd.org> wrote:
>
>
>
>> On Mar 7, 2016, at 2:59 AM, Robert Watson <rwatson at FreeBSD.org> wrote:
>>
>> 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).
>
> It would be nice to have NFSv4 / Solaris style alternate data streams. ZFS handles them already, but I suppose it would take more work to support them in UFS.
>
>> 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.
>
> It may be that for at least the purposes of FUSE, we can adequately live under the USER namespace. That would allow for arbitrary namespaces that Linux-centric filesystems create without significant churn in FreeBSD to support it.
>
> And of course this is only for the front/top end of a FUSE filesystem. What the filesystem actually does with the extended attributes that the user sets on top is another question altogether. In the case of IBM’s LTFS, it stores extended attributes (without the “user.” prefix) in the LTFS index, which is an XML file that resides on tape. For other filesystems, the answer could also vary significantly. A few that I examined in sysutils/fusefs* used extended attributes on the backend (usually on a backing filesystem) under Linux only, but not on the front (user facing) end.
>
> In order to make arbitrary namespaces in FUSE work in FreeBSD under the user namespace, we’ll have to do what Rick was talking about and just not include the namespace as a prefix when we get/set attributes. This will allow using any sort of namespace or attribute name that the FUSE filesystem wants to use.
>
> The impact of this, from a porting standpoint, is that the FUSE filesystems will have to know that on FreeBSD, they cannot/should not expect to see the “user.” namespace prefix, but they might see other namespace prefixes.
>
> I took a look at the way LTFS and Gluster work with respect to extended attributes with MacOS, since it seems that is how MacOS works, and it’s less obvious to me what is going on with Gluster. They’ve got this function:
>
> #ifdef GF_DARWIN_HOST_OS
> static int
> set_xattr_user_namespace_mode (struct posix_private *priv, const char *str)
> {
> if (strcmp (str, "none") == 0)
> priv->xattr_user_namespace = XATTR_NONE;
> else if (strcmp (str, "strip") == 0)
> priv->xattr_user_namespace = XATTR_STRIP;
> else if (strcmp (str, "append") == 0)
> priv->xattr_user_namespace = XATTR_APPEND;
> else if (strcmp (str, "both") == 0)
> priv->xattr_user_namespace = XATTR_BOTH;
> else
> return -1;
> return 0;
> }
> #endif
>
> Although it’s not clear that they do anything with values other than XATTR_STRIP.
>
> With LTFS, since they either assume a “user.” prefix on Linux, or no prefix on Windows and MacOS X, it’s more straightforward.
>
> Ken
>
>
>>
>> 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"
>
>
>
> —
> Ken Merry
> ken at FreeBSD.ORG
>
>
>
More information about the freebsd-scsi
mailing list