The test for 'follow symlinks = no' (CVE-2017-2619) fails from time to time. The log file reports a DB corruption. The failing test is: samba3.blackbox.smbclient_s3.sign (nt4_dc).follow symlinks = no(nt4_dc) Failure: 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? Log snippet: streams_depot_stat called for [test/foo/bar/testfile] [2017/04/28 11:20:10.644377, 10, pid=22257, effective(0, 0), real(0, 0), class=vfs] ../source3/lib/xattr_tdb.c:183(xattr_tdb_getattr) xattr_tdb_getattr called for file fd00:40124b72:0, name security.NTACL [2017/04/28 11:20:10.644388, 10, pid=22257, effective(0, 0), real(0, 0), class=vfs] ../source3/lib/xattr_tdb.c:189(xattr_tdb_getattr) xattr_tdb_fetch_attrs failed: NT_STATUS_INTERNAL_DB_CORRUPTION
Created attachment 13178 [details] Patch for more debug output
Created attachment 13179 [details] logs.tar.xz
There're also a lot of flakey test which report corrupted file names.
(In reply to Stefan Metzmacher from comment #4) See https://git.samba.org/autobuild.flakey.sn-devel-144/2017-03-29-1235/samba.stdout https://git.samba.org/autobuild.flakey.sn-devel-144/2017-04-11-1234/samba.stdout https://git.samba.org/autobuild.flakey.sn-devel-144/2017-04-08-0635/samba.stdout
(In reply to Andreas Schneider from comment #2) I can't find 'pid=22257' in any of the attached log files.
I reproduced it more than once. Search for 'testfile' in log.client.
623227 [2017/04/28 15:56:08.099012, 10, pid=28656, effective(1000, 100), real(1000, 0), class=vfs] ../source3/lib/xattr_tdb.c:184(xattr_tdb_getattr) 623228 xattr_tdb_getattr called for file fd00:60060dce:0, name user.DOSATTRIB 623229 [2017/04/28 15:56:08.099023, 0, pid=28656, effective(1000, 100), real(1000, 0), class=vfs] ../source3/lib/xattr_tdb.c:118(xattr_tdb_load_attrs) 623230 xattr_tdb_load_attrs: XXXXXX: status=NT_STATUS_NOT_FOUND 623231 [2017/04/28 15:56:08.099033, 10, pid=28656, effective(1000, 100), real(1000, 0), class=vfs] ../source3/lib/xattr_tdb.c:190(xattr_tdb_getattr) 623232 xattr_tdb_fetch_attrs failed: NT_STATUS_INTERNAL_DB_CORRUPTION With an additional debug line, you can see that NT_STATUS_NOT_FOUND is what dbwrap_fetch() returns in xattr_tdb_load_attrs() but then we return NT_STATUS_INTERNAL_DB_CORRUPTION as the error. Maybe a) either this is the wrong return value or b) there should be an entry. However since the file is created by the test script there cannot be an entry in the DB. Maybe because we do not have a DB entry we might return uninitialized memory somewhere. valgrind didn't find something.
Should this bug still be embargoed?
(In reply to Andrew Bartlett from comment #9) Hm, I don't see any security implications here.