[PATCH] vfs module for VxFS

[Jeremy Allison]

On Tue, Sep 02, 2014 at 11:52:49AM +1200, Andrew Bartlett wrote:
> 
> The concern I have is that Samba can permit access to extended
> attributes directly.  You have to ban them in samba_private_attr_name()
> in source3/smbd/trans2.c. 

Good catch Andrew !

> While I understand your module is essentially for your own use, others
> will probably copy from it, and if they don't also know to update the
> samba_private_attr_name() code in trans2.c to ban access, and if their
> system is more option than yours, they may unwittingly have a security
> issue.
> 
> I don't have a good solution, except perhaps clear and prominent
> comments, but I'm not comfortable with this in our upstream code.  

Let's not block vendors who are trying to do
the right thing by upstreaming their code. We
don't want to get a reputation of being difficult
to work with for vendors here :-).

We need to encourage upstreaming of formally
private VFS modules as much as possible.

> Can anyone else see a better way out of this?  

Well, as the build system changes explicitly
set a HAVE_VXFS c flag, we can easily add this
to the samba_private_attr_name() array - probably
via adding a catchall entry such as:

iff --git a/source3/smbd/trans2.c b/source3/smbd/trans2.c
index f1ccc7e..7d71158 100644
--- a/source3/smbd/trans2.c
+++ b/source3/smbd/trans2.c
@@ -127,6 +127,7 @@ bool samba_private_attr_name(const char *unix_ea_name)
                SAMBA_XATTR_DOS_ATTRIB,
                SAMBA_XATTR_MARKER,
                XATTR_NTACL_NAME,
+               FILESYSTEM_SPECIFIC_PROHIBITED_EA_NAMES,
                NULL
        };


and having this being pulled in via a header file.

If we really want to make this more generic, and
remember I'm expecting a lot more vendor VFS
modules to be forthcoming over the years as we
expand our coverage :-) maybe we could add a
VFS function to filter a proposed EA name.

As this is for 4.2.x that would be a reasonable
change to make.

Thoughts ?

Jeremy.