samba - Apr 2018 - Operation Not Supported error for GETXATTR when VFS plugin "nfs4acl_xattr" is used

On Fri, Apr 06, 2018 at 12:40:31PM -0700, Jeremy Allison
wrote:
> On Fri, Apr 06, 2018 at 09:22:17PM +0200, Ralph Böhme wrote:
> > On Fri, Apr 06, 2018 at 10:27:32AM -0700, Jeremy Allison via samba
wrote:
> > > On Fri, Apr 06, 2018 at 01:44:50PM +0530, Akash Jain wrote:
> > > > Hi All
> > > > 
> > > > I found there is one bug in the plugin. The name of the
attribute for ACL as
> > > > per strace output of nfs4_setfacl is system.nfs4_acl.
> > > > The source code has defined it as
> > > > #define NFS4ACL_XATTR_NAME      ( "system.nfs4acl"
)
> > > > 
> > > > Note there is missing underscore.
> > > > 
> > > > After this, the EOPNOTSUPP error is not observed.
> > > > 
> > > > Hope this helps
> > > 
> > > Hmmm. This has been changed for Samba 4.8.0 and above,
> > > with commit df99ac27106dededcf0a98a251e58c24b90bf6d1.
> > > 
> > > This would seem to be a correct fix, as it seems
> > > 
> > > "The "system" xattr namespace is reserved for the
kernel. Any attempt to
> > >     use xattrs in that namesspace will fail with EOPNOTSUPP,
regardless of
> > >     priveleges."
> > > 
> > > Can you check with 4.8.x ?
> > 
> > I guess that statement may not be correct, depending on which kernel
subsystem
> > exposes the xattr? My testing was with local filesytems, not with
nfsv4
> > mounts. Apparantly it works with nfs4_getfacl|nfs4_setfacl...
> 
> Ah, my guess is there's a missing check in the kernel
> NFSv4 redirector somewhere. Anyway, we can't use system.XXX
> namespace if it doesn't work on local filesystems on
> Linux.
the good thing is with the new module it's configurable...

-slow

-- 
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG Key Fingerprint:           FAE2 C608 8A24 2520 51C5
                               59E4 AA1E 9B71 2639 9E46

On Fri, Apr 06, 2018 at 09:28:16PM +0200, Ralph Böhme
wrote:
> On Fri, Apr 06, 2018 at 12:40:31PM -0700, Jeremy Allison wrote:
> > On Fri, Apr 06, 2018 at 09:22:17PM +0200, Ralph Böhme wrote:
> > > On Fri, Apr 06, 2018 at 10:27:32AM -0700, Jeremy Allison via
samba wrote:
> > > > On Fri, Apr 06, 2018 at 01:44:50PM +0530, Akash Jain wrote:
> > > > > Hi All
> > > > > 
> > > > > I found there is one bug in the plugin. The name of the
attribute for ACL as
> > > > > per strace output of nfs4_setfacl is system.nfs4_acl.
> > > > > The source code has defined it as
> > > > > #define NFS4ACL_XATTR_NAME      (
"system.nfs4acl" )
> > > > > 
> > > > > Note there is missing underscore.
> > > > > 
> > > > > After this, the EOPNOTSUPP error is not observed.
> > > > > 
> > > > > Hope this helps
> > > > 
> > > > Hmmm. This has been changed for Samba 4.8.0 and above,
> > > > with commit df99ac27106dededcf0a98a251e58c24b90bf6d1.
> > > > 
> > > > This would seem to be a correct fix, as it seems
> > > > 
> > > > "The "system" xattr namespace is reserved for
the kernel. Any attempt to
> > > >     use xattrs in that namesspace will fail with EOPNOTSUPP,
regardless of
> > > >     priveleges."
> > > > 
> > > > Can you check with 4.8.x ?
> > > 
> > > I guess that statement may not be correct, depending on which
kernel subsystem
> > > exposes the xattr? My testing was with local filesytems, not with
nfsv4
> > > mounts. Apparantly it works with nfs4_getfacl|nfs4_setfacl...
> > 
> > Ah, my guess is there's a missing check in the kernel
> > NFSv4 redirector somewhere. Anyway, we can't use system.XXX
> > namespace if it doesn't work on local filesystems on
> > Linux.
> 
> the good thing is with the new module it's configurable...
Oh I didn't spot that, so it is ! Well done that man :-) :-).

Hello Jeremy and Ralph

Thanks for your suggestions.

I compiled samba-4.8.0 and running it instead of samba-4.6.2. I saw the
changes that you mentioned in the latest vfs_nfs4acl_xattr module.

The operation not supported error is gone but it is now failing with access
denied. Here is what I tried:








*[root at test3 ajain]# net conf showshare local[local]        path
/home/ajain/mount        comment = local share        guest ok = no
read only = no        hosts allow = ALL        vfs objects = nfs4acl_xattr*

*        nfs4acl_xattr:xattr_name = system.nfs4_acl
nfs4acl_xattr:encoding = xdr*

I added/enabled some debug messages and here is what I see for XDR type:

















*[2018/04/09 21:53:34.024425,  3, pid=32098, effective(1101151, 1100513),
real(1101151, 0)] ../source3/smbd/trans2.c:2667(call_trans2findfirst)
call_trans2findfirst: dirtype = 16, maxentries = 1366, close_after_first=0,
close_if_end = 1 requires_resume_key = 1 backup_priv = 0 level = 0x104,
max_data_bytes = 65535[2018/04/09 21:53:34.024788,  3, pid=32098,
effective(1101151, 1100513), real(1101151, 0)]
../source3/modules/vfs_nfs4acl_xattr.c:286(nfs4acl_xattr_get_nt_acl)
nfs4acl_xattr_get_nt_acl: nfs4acl_xattr_get_nt_acl[2018/04/09
21:53:34.024998,  3, pid=32098, effective(1101151, 1100513), real(1101151,
0)] ../source3/modules/vfs_nfs4acl_xattr.c:230(nfs4acl_blob_to_smb4)
nfs4acl_blob_to_smb4: NFS4ACL_ENCODING_XDR[2018/04/09 21:53:34.025027,  3,
pid=32098, effective(1101151, 1100513), real(1101151, 0)]
../source3/modules/nfs4acl_xattr_xdr.c:398(nfs4acl_xdr_blob_to_smb4)
nfs4acl_xdr_blob_to_smb4: nfs4acl_xdr_blob_to_smb4[2018/04/09
21:53:34.025043,  3, pid=32098, effective(1101151, 1100513), real(1101151,
0)]
../source3/modules/nfs4acl_xattr_xdr.c:286(nfs4acl_xdr_blob_to_nfs4acl)
nfs4acl_xdr_blob_to_nfs4acl: nfs4acl_xdr_blob_to_nfs4acl[2018/04/09
21:53:34.025053,  3, pid=32098, effective(1101151, 1100513), real(1101151,
0)]
../source3/modules/nfs4acl_xattr_xdr.c:293(nfs4acl_xdr_blob_to_nfs4acl)
nfs4acl_xdr_blob_to_nfs4acl: naces = 50[2018/04/09 21:53:34.025076,  3,
pid=32098, effective(1101151, 1100513), real(1101151, 0)]
../source3/modules/nfs4acl_xattr_xdr.c:339(nfs4acl_to_smb4acl)
nfs4acl_to_smb4acl: flags [8008] nace [0][2018/04/09 21:53:34.025147,  3,
pid=32098, effective(1101151, 1100513), real(1101151, 0)]
../source3/smbd/error.c:82(error_packet_set)  NT error packet at
../source3/smbd/trans2.c(2857) cmd=50 (SMBtrans2) NT_STATUS_ACCESS_DENIED*

There are not more than 4 ACEs on the root directory but we see naces = 50.
I feel that the encoding of ACL is not happening as expected.

Can you please post what kind of basic tests that succeed with
NFS4ACL_XATTR VFS module?

I appreciate your help.

Thanks
Akash



On Sat, Apr 7, 2018 at 1:16 AM, Jeremy Allison <jra at samba.org> wrote:
> On Fri, Apr 06, 2018 at 09:28:16PM +0200, Ralph Böhme wrote:
> > On Fri, Apr 06, 2018 at 12:40:31PM -0700, Jeremy Allison wrote:
> > > On Fri, Apr 06, 2018 at 09:22:17PM +0200, Ralph Böhme wrote:
> > > > On Fri, Apr 06, 2018 at 10:27:32AM -0700, Jeremy Allison via
samba
> wrote:
> > > > > On Fri, Apr 06, 2018 at 01:44:50PM +0530, Akash Jain
wrote:
> > > > > > Hi All
> > > > > >
> > > > > > I found there is one bug in the plugin. The name
of the
> attribute for ACL as
> > > > > > per strace output of nfs4_setfacl is
system.nfs4_acl.
> > > > > > The source code has defined it as
> > > > > > #define NFS4ACL_XATTR_NAME      (
"system.nfs4acl" )
> > > > > >
> > > > > > Note there is missing underscore.
> > > > > >
> > > > > > After this, the EOPNOTSUPP error is not observed.
> > > > > >
> > > > > > Hope this helps
> > > > >
> > > > > Hmmm. This has been changed for Samba 4.8.0 and above,
> > > > > with commit df99ac27106dededcf0a98a251e58c24b90bf6d1.
> > > > >
> > > > > This would seem to be a correct fix, as it seems
> > > > >
> > > > > "The "system" xattr namespace is
reserved for the kernel. Any
> attempt to
> > > > >     use xattrs in that namesspace will fail with
EOPNOTSUPP,
> regardless of
> > > > >     priveleges."
> > > > >
> > > > > Can you check with 4.8.x ?
> > > >
> > > > I guess that statement may not be correct, depending on
which kernel
> subsystem
> > > > exposes the xattr? My testing was with local filesytems, not
with
> nfsv4
> > > > mounts. Apparantly it works with
nfs4_getfacl|nfs4_setfacl...
> > >
> > > Ah, my guess is there's a missing check in the kernel
> > > NFSv4 redirector somewhere. Anyway, we can't use system.XXX
> > > namespace if it doesn't work on local filesystems on
> > > Linux.
> >
> > the good thing is with the new module it's configurable...
>
> Oh I didn't spot that, so it is ! Well done that man :-) :-).
>