[PATCH v1] xfstests: filter the default EA

[Steve French]

Adding Samba technical.

Interesting that (apparently) it isn't returned by the local xfs
"getfattr" from bash but is picked up when Samba server queries xfs
for xattrs.  Strange

On Thu, Dec 20, 2018 at 10:01 PM Xiaoli Feng <xifeng at redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Steve French" <smfrench at gmail.com>
> > To: "Xiaoli Feng" <xifeng at redhat.com>
> > Cc: "Christoph Hellwig" <hch at infradead.org>, fstests at vger.kernel.org, "Ronnie Sahlberg" <lsahlber at redhat.com>, "CIFS"
> > <linux-cifs at vger.kernel.org>
> > Sent: Thursday, December 20, 2018 1:37:57 PM
> > Subject: Re: [PATCH v1] xfstests: filter the default EA
> >
> > On Wed, Dec 19, 2018 at 11:23 PM Xiaoli Feng <xifeng at redhat.com> wrote:
> > >
> > > Hello,
> > >
> > > ----- Original Message -----
> > > > From: "Steve French" <smfrench at gmail.com>
> > > > To: "Xiaoli Feng" <xifeng at redhat.com>
> > > > Cc: "Christoph Hellwig" <hch at infradead.org>, fstests at vger.kernel.org,
> > > > "Ronnie Sahlberg" <lsahlber at redhat.com>, "CIFS"
> > > > <linux-cifs at vger.kernel.org>
> > > > Sent: Thursday, December 20, 2018 11:53:09 AM
> > > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > > >
> > > > What server type (presumably Samba if mounting to localhost)?  What
> > >
> > > Yes, it's Samba.
> > <snip>
> > > The dialect is smb3.02.
> >
> > Since cifs.ko does not know about or special case this attribute, the
> > next step is to figure out who is returning this attribute - Samba
> > server or something above the client.
> > Typically I approach this by doing a quick wireshark trace (or follow
> > the process described at
> > https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures),
> > that will very quickly allow you to determine if it even came from the
> > server.  If it came from the server, follow the normal process for
> > enabling Samba logging (setting log level in smb.conf and looking at
> > why the xattr is being returned by examining the corresponding log
> > file in /var/log/samba/).   If you don't see it coming from the
> > server, then enabling the usual dynamic trace (trace-cmd) of the
> > syscall may be helpful.
> > Note that there are a fairly large number of xattr related trace
> > points (see /sys/kernel/tracing/events/syscalls).  Looking at this
> > does remind me that I should add dynamic trace points to cifs.ko for
> > smb3_get/set xattrs (for the error and success cases) although it
> > probably wouldn't be needed in this case - it would have allowed us to
> > more quickly rule out Samba returning this.
>
> This EA information is returned from Samba server.
>
> GetInfo Response (0x10)
>         [Class: FILE_INFO (0x01)]
>         [InfoLevel: SMB2_FILE_FULL_EA_INFO (0x0f)]
>         StructureSize: 0x0009
>             0000 0000 0000 100. = Fixed Part Length: 4
>             .... .... .... ...1 = Dynamic Part: True
>         Blob Offset: 0x00000048
>         Blob Length: 56
>         SMB2_FILE_FULL_EA_INFO
>             EA: security.selinux := unconfined_u:object_r:mnt_t:s0
>                 Next Offset: 0
>                 EA Flags: 0x00
>                 EA Name Length: 16
>                 EA Data Length: 31
>                 EA Name: security.selinux
>                 EA Data: 756e636f6e66696e65645f753a6f626a6563745f723a6d6e...
>
>
> >
> > > > What does the getfattr on the local path show as the attributes?
> > >
> > > It shows nothing for local path on xfs filesystem.
> > >
> > > # touch /file
> > > # getfattr /file
> > > #
> >



-- 
Thanks,

Steve