[FAILING TEST] The no symlink follow test for CVE-2017-2619 is failing sometimes

[Jeremy Allison]

On Fri, Apr 28, 2017 at 06:21:24PM +0200, Ralph Böhme wrote:
> On Fri, Apr 28, 2017 at 09:11:25AM -0700, Jeremy Allison via samba-technical wrote:
> > On Fri, Apr 28, 2017 at 11:48:47AM +0200, Andreas Schneider wrote:
> > > Hi Jeremy,
> > > 
> > > the test samba3.blackbox.smbclient_s3.sign (nt4_dc).follow symlinks = 
> > > no(nt4_dc) sometimes fails for me, and I think we also saw it in autobuild 
> > > failing too. The failure looks like that:
> > > 
> > > NT_STATUS_FILE_IS_A_DIRECTORY opening remote file \test\foo\bar\testfile
> > > 
> > > ls -la /home/asn/workspace/projects/samba/st/ad_member/share/nosymlinks/test/
> > > foo/bar/
> > > total 4                                     
> > > drwxrwxrwx 2 asn asn-group 22 Apr 28 11:42 .    
> > > drwxrwxrwx 3 asn asn-group 17 Apr 28 11:42 ..
> > > -rw-rw-rw- 1 asn asn-group 87 Apr 28 11:42 testfile
> > > 
> > > Domain=[SAMBADOMAIN] OS=[] Server=[]                                    
> > > smb: \> cd test\foo\bar
> > > smb: \test\foo\bar\> ls                             
> > >   .                                   D        0  Fri Apr 28 11:42:55 2017
> > >   ..                                  D        0  Fri Apr 28 11:42:55 2017
> > >   testfile                            D        0  Fri Apr 28 11:42:55 2017  
> > >                                                                            
> > >                 976281660 blocks of size 1024. 525524304 blocks available    
> > > smb: \test\foo\bar\> get testfile -                     
> > > NT_STATUS_FILE_IS_A_DIRECTORY opening remote file \test\foo\bar\testfile    
> > > smb: \test\foo\bar\> quit                              
> > > failed - NT_STATUS_XXXX doing cd foo\bar; get testfile on \nosymlinks
> > > 
> > > As you can see, 'ls' tells us 'testfile' is a directory, but it isn't as you 
> > > can see from the local 'ls -la' command. The question is why does it report a 
> > > file as directory?
> > 
> > This might happen if xattrs storing the DOS modes are being stored
> > in a tdb, and a dev/ino pair got re-used without the old entry being
> > cleared out.
> > 
> > An xattr read for dos attributes might then return the wrong values.
> > 
> > That's my current best guess. Can we work on this together next week
> > at SambaXP - that way you can make it my problem in person :-) ?
> 
> hm, didn't Uri (or someone else, don't remember) fix an issue in this area a
> short while (like within the last 12 months) ago?

Yes, that and the work you did on setting default dos attributes
I reviewed a while ago made me think of this.

But to be honest we'll probably only nail this when Andreas
and I are discussing his laptop over a beer :-).