FUSE extended attribute patches available

Rick Macklem rmacklem at uoguelph.ca
Tue Mar 8 02:39:18 UTC 2016


Ken Merry 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.
> 
When this was discussed previously, Jordan Hubbard pointed out that most of the
work is making sure the userland utilities (like backup utilities...) know about them
and what to do with them.

I am not familiar with the userland issue, but if that was resolved, personally, I don't think
a lack of support in UFS would be a showstopper. (Assuming that it would be an
addition and not a replacement for extended attributes.)

I do recall that someone at Cern is adamant about this. (I think they create file
forks with Gbytes of data and can't live without them.)

> > 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-fs mailing list