[PATCH 21/21] hfsplus: remove can_set_xattr

[Vyacheslav Dubeyko]

On Sun, 2013-12-22 at 11:28 -0800, Christoph Hellwig wrote:

> 
> > > -	if (!strncmp(name, XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN)) {
> > > -		/*
> > > -		 * This makes sure that we aren't trying to set an
> > > -		 * attribute in a different namespace by prefixing it
> > > -		 * with "osx."
> > > -		 */
> > > -		if (is_known_namespace(name + XATTR_MAC_OSX_PREFIX_LEN))
> > > -			return -EOPNOTSUPP;
> > 
> > I think that this check is important. It forbids such combinations as "osx.system.*" or
> > "osx.trusted.*", for example. Because "osx.*" is virtual namespace for xattrs that
> > it can be under Mac OS X. If you want to set xattr from "system.*" namespace, for example,
> > then you need to use another handler. And such namespace should be without
> > addition of "osx." prefix.
> 
> Right, and we keep exactly the check, just in a different place.
> 

Maybe I missed something, but I can see that this check is removed only.
Could you point out the code in your patch that it checks and forbids
such combination as "osx.security.*", "osx.trusted.*" and so on?

I can see that is_known_namespace() is called for
hfsplus_xattr_osx_handler only. But this method doesn't contain
above-mentioned check. Moreover, hfsplus_xattr_user_handler,
hfsplus_xattr_trusted_handler, hfsplus_xattr_security_handler will be
without is_know_namespace() check. What about it?

> > The __hfsplus_setxattr() is common method for all handlers. So, removing
> > this call means that we don't check validity of namespace. I don't think
> > that such modification is a right way.
> 
> The generic code already checks for the validity of the namespace for
> you. xattr_resolve_name in fs/xattr.c makes sure only attributes for a
> namespace that the filesystem registered can be set or modified.
> 

But generic code doesn't check such names combination that it is treated
as wrong for concrete file systems. For example, "osx.security.*" is
wrong for the case of HFS+. Because it will works
hfsplus_xattr_osx_handler instead of hfsplus_xattr_security_handler.

> > > @@ -841,10 +761,6 @@ int hfsplus_removexattr(struct dentry *dentry, const char *name)
> > > 	if (!HFSPLUS_SB(inode->i_sb)->attr_tree)
> > > 		return -EOPNOTSUPP;
> > > 
> > > -	err = can_set_xattr(inode, name, NULL, 0);
> > 
> > Ditto. Moreover, it is used namely hfsplus_removexattr() and not
> > __hfsplus_setxattr() for removing xattrs in hfsplus driver. So, removing
> > this check is not good way.
> 
> Oh, I just noticed that hfsplus does not use the xattr handlers for
> removing, while it does for getting and setting xattrs.  That's a really
> bad a confusing design, and we'll indeed need to fix that as well.
> 

Why bad design? Do you mean that using .removexattr callback is bad
idea?

So, if it needs to use xattr handler only for removing then it needs to
make some refactoring of using __hfsplus_setxattr() and
hfsplus_removexattr() or merging these two functions into one. And I
think that merging is better idea.

Thanks,
Vyacheslav Dubeyko.