Samba 3.5.4 (and 3.6) fails when smbtorture4 test BASE-TCONDEV. The test tries to connect with tcon with different devices with share IPC$ and a real share name, and expects to fail on the different device name. but succeeds. In order to reproduce just run the BASE-TCONDEV test as follows: Test output: #smbtorture //samb_server/share -U domain/administrator%password --option=torture:samba3=true BASE-TCONDEV Using seed 1299692376 test: TCONDEV Trying share IPC$ with devtype A: failure: TCONDEV [ torture/basic/base.c:104: tconx to share IPC$ with type A: should have failed but succeeded ] the following log.smbd shows that it doesn't parse the device string ("A:") from the packet. So it proceed to assume it is a normal IPC$ tcon call and treats it as one. Please note the log is taken from samba3.6.0 [2011/03/09 19:39:36.994225, 10] ../lib/util/util.c:415(dump_data) [0000] 00 49 00 50 00 43 00 24 00 00 00 41 3A 00 .I.P.C.$ ...A:. [2011/03/09 19:39:36.994308, 3] smbd/process.c:1456(switch_message) switch message SMBtconX (pid 13823) conn 0x0 [2011/03/09 19:39:36.994375, 3] smbd/sec_ctx.c:311(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2011/03/09 19:39:36.994440, 5] ../libcli/security/security_token.c:53(security_token_debug) Security token: (NULL) [2011/03/09 19:39:36.994509, 5] auth/token_util.c:653(debug_unix_user_token) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2011/03/09 19:39:36.994610, 5] smbd/uid.c:371(change_to_root_user) change_to_root_user: now uid=(0,0) gid=(0,0) [2011/03/09 19:39:36.994681, 4] smbd/reply.c:786(reply_tcon_and_X) Client requested device type [] for share [IPC$] [2011/03/09 19:39:36.994763, 5] smbd/service.c:1252(make_connection) making a connection to 'normal' service ipc$ [2011/03/09 19:39:36.994829, 3] lib/access.c:334(allow_access) Allowed connection from ::ffff:10.48.29.140 (::ffff:10.48.29.140) [2011/03/09 19:39:36.994899, 10] smbd/share_access.c:238(user_ok_token) user_ok_token: share IPC$ is ok for unix user administrator On this issue - is there a documented list of smbtorture4 tests that pass/fail on Samba3.X ? Best regards, Eyal Marcus
Created attachment 6289 [details] Fix for 3.5.next. When pulling non-aligned ucs2 strings, we neglected to add in the pad byte to the buffer length we've eaten. This caused the device string in TCONX (which seems to be one of the few places that uses non-aligned ucs2 strings) to be incorrectly read. Volker please check. Jeremy.
Pushed to v3-5-test. Will be included in the next 3.5 release. Closing out bug report. Thanks!