Re: [PATCH v2 3/4] hfsplus: rework functionality of getting, setting and deleting of extended attributes

[Vyacheslav Dubeyko <slava@dubeyko.com>]

Hi,

On Wed, 2012-09-26 at 08:13 -0400, Christoph Hellwig wrote:
> On Tue, Sep 25, 2012 at 02:57:04PM +0400, Vyacheslav Dubeyko wrote:
> > As I can understand, you are talking about using xattr_handler's for
> > dispatching of processing of extended attributes with such complex names
> > as "system.posix_acl_access" and so on. Am I correct?
> > 
> > The HFS+ has such peculiarities that you can name extended attribute as
> > you want. And name of extended attribute can keep in Attributes Tree
> > without any prefixes (for example, as "test"). Moreover, it is not used
> > such prefixes as "user." or "system." under Mac OS X.
> 
> But we will have to use them under Linux.  The whole xattr mechanism
> is built around the model that we decide policies, including most
> importantly access control, based on these prefixes.  In retrospective
> I think the string prefixes are a horrible idea and a simple binary
> flag namespace as done by e.g. IRIX or FreeBSD would have made everyones
> life a heck lot simpler, but that's not what we implemented 10 years
> ago.
> 
> > However, it exists under Mac OS X special prefix "com.apple." (for
> > example, "com.apple.FinderInfo"). So, you suggest to add definition of
> > additional prefixes "com." and "apple." in include/linux/xattr.h and to
> > add xattr_handler's for these two prefixes. Am I correct?
> 
> No.  I'd suggest mapping any free-form attributes in hfsplus into user.*
> in the syscall namespace, while only mapping a few that needs special
> treatment into system.* or similar.  Using the proper helpers will make
> this actually readable at least.
> 

So, it means that it needs to add special prefix "user." during
listxattr phase for any free-form attributes. And then it needs to
expect on the getxattr phase names with artificially added prefixes (for
example, user.<real-name>) and ignores requests with only real name of
attribute (real name means name of extended attribute that keeps in
metadata).

But it can really confuse, from my point of view. Let's imagine that you
firstly, mount your HFS+ volume under Mac OS X and, secondly, under
Linux. Under Mac OS X you can see real names of the extended attributes
but under Linux you will see another artificially constructed names of
extended attributes for the same file system object:

Mac OS X -> "test"
Linux -> "user.test"

I think this situation can be a very confusing and unexpected for the
end-user. For example, if I remember extended attribute name that I got
under Mac OS X then I can try to get it content by name under Linux (but
will fail in such situation).

I totally agree that it needs to implement prefixes support for the ACLs
case. But I think that it is not proper way for free-form extended
attributes. It needs to remember about possible using the same HFS+
volume as under Mac OS X as under Linux.

With the best regards,
Vyacheslav Dubeyko.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html