Bug 7950 - Samba 3.5.x fails BASE-CREATEX_SHAREMODES_DIR smbtorture4 test
Samba 3.5.x fails BASE-CREATEX_SHAREMODES_DIR smbtorture4 test
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.6
x64 Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-09 09:48 UTC by Volodymyr Khomenko
Modified: 2011-03-01 14:30 UTC (History)
0 users

See Also:


Attachments
Patch for 3.5.x. (2.73 KB, patch)
2011-02-23 20:20 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volodymyr Khomenko 2011-02-09 09:48:58 UTC
Samba 3.5.x fails smbtorture4 BASE-CREATEX_SHAREMODES_DIR test:

# source4/bin/smbtorture //samba_IP/Admin -U Admin%password BASE-CREATEX_SHAREMODES_DIR
Using seed 1297258152
test: CREATEX_SHAREMODES_DIR
WARNING!: (torture/basic/denytest.c:2366) Incorrect status NT_STATUS_OBJECT_NAME_NOT_FOUND - should be NT_STATUS_OK

  { .cxd_test = 2, .cxd_flags = 0x1, .cxd_access1 =          0, .cxd_sharemode1=0, .cxd_access2=         0, .cxd_sharemode2=0, .cxd_result = { NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OBJECT_NAME_NOT_FOUND, }, .cxd_result2 = { NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OBJECT_NAME_NOT_FOUND, }},

...

failure: CREATEX_SHAREMODES_DIR [
(torture/basic/denytest.c:2372) Incorrect status NT_STATUS_OBJECT_NAME_NOT_FOUND - should be NT_STATUS_OK

Test creates a directory (named createx_dir\) and a file in that directory (named createx_dir\known) using absolute path (Root FID is 0) via NTCreateAndX request. Then it tries to access the known file with relative path (Root FID is the FID returned during the creation of the parent directory). When doing this, it gets STATUS_OBJECT_NAME_NOT_FOUND.

Seems like the issue is NOT related to sharemode at all: the test fails for all combinations of sharemode. The only reason of failure is relative path (non-zero Root FID).

Problematic flow is: reply_ntcreate_and_X -> SMB_VFS_CREATE_FILE(vfswrap_create_file) -> create_file_default -> create_file_unixpath -> open_file_ntcreate.

Key log messages are below:

[2011/02/09 17:18:49.343654, 10] smbd/nttrans.c:501(reply_ntcreate_and_X)
  reply_ntcreate_and_X: flags = 0x0, access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 root_dir_fid = 0x2376, fname = known

[2011/02/09 17:18:49.344665, 10] smbd/open.c:3541(create_file_default)
  create_file: access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x0 private_flags = 0x0 root_dir_fid = 0x2376, ea_list = 0x(nil), sd = 0x(nil), fname = known

[2011/02/09 17:18:49.344853, 10] smbd/vfs.c:974(check_reduced_name)
  check_reduced_name realpath [createx_dir/known] -> [/home/Admin/createx_dir/known]

[2011/02/09 17:18:49.344963, 10] smbd/open.c:3068(create_file_unixpath)
  create_file_unixpath: access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x0 private_flags = 0x0 ea_list = 0x(nil), sd = 0x(nil), fname = createx_dir/known

[2011/02/09 17:18:49.345267, 10] smbd/open.c:1612(open_file_ntcreate)
  open_file_ntcreate: fname=createx_dir/known, dos_attrs=0x80 access_mask=0x1f01ff share_access=0x0 create_disposition = 0x1 create_options=0x0 unix mode=0744 oplock_request=0 private_flags = 0x0

[2011/02/09 17:18:49.345487,  3] smbd/vfs.c:1036(check_reduced_name)
  check_reduced_name: createx_dir/known reduced to /home/Admin/createx_dir/known

[2011/02/09 17:18:49.345559,  5] smbd/open.c:1702(open_file_ntcreate)
  open_file_ntcreate: FILE_OPEN requested for file createx_dir/known and file doesn't exist.

[2011/02/09 17:18:49.345860, 10] smbd/open.c:3374(create_file_unixpath)
  create_file_unixpath: NT_STATUS_OBJECT_NAME_NOT_FOUND

From my point of view, the reason of failure is: the file cannot be stat'ed correctly until related filename ('known') is mapped to absolute ('createx_dir/known'). So all STATs until the call create_file_default->get_relative_fid_filename are not successful. Still after filename translation no STAT call is done any more, so translated smb_fname parameter contains invalid stat buffer. create_file_default attaches this smb_fname to new (created by file_new) fsp and calls open_file_ntcreate.
Then
bool file_existed = VALID_STAT(smb_fname->st);
inside open_file_ntcreate means that the file is considered as non-existent, so due used create_disposition=FILE_OPEN we cannot open it... ENOENT/NT_STATUS_OBJECT_NAME_NOT_FOUND are returned for existent file...

P.S. Bug is reproducible for current samba 3.5.x (fetched from git).

Thanks.
Comment 1 Jeremy Allison 2011-02-23 13:30:26 UTC
I have a patch for this currently under test. Give me a day or so...

Thanks,

Jeremy.
Comment 2 Jeremy Allison 2011-02-23 20:20:32 UTC
Created attachment 6268 [details]
Patch for 3.5.x.

Please test - if it passes your testing (it does here) I'll get Volker to review to get this into 3.5.next.

Jeremy.
Comment 3 Volodymyr Khomenko 2011-02-24 05:03:25 UTC
Yes, tested on samba 3.5.4 - provided patch works as expected:

[source4]# ./bin/smbtorture //172.41.45.10/share -U Admin%password BASE-CREATEX_SHAREMODES_DIR
Using seed 1267008222
test: CREATEX_SHAREMODES_DIR
 4096/ 4096 (0 skipped)
success: CREATEX_SHAREMODES_DIR

Thanks for support!
Comment 4 Jeremy Allison 2011-02-24 11:21:41 UTC
Comment on attachment 6268 [details]
Patch for 3.5.x.

Volker, please review for 3.5.next. Submitter confirms it works (and checked into master and 3.6.0).

Jeremy.
Comment 5 Volker Lendecke 2011-02-26 10:05:30 UTC
Comment on attachment 6268 [details]
Patch for 3.5.x.

Looks good, thanks.
Comment 6 Volker Lendecke 2011-02-26 10:06:53 UTC
Karolin, this is 916e82823b56a70d7761644b38a250ea8c38e204 in master. The attachment here is not git am -3 format. The mentioned hash is equivalent and cleanly was applicable for me with git am -3.

Thanks,

Volker
Comment 7 Karolin Seeger 2011-03-01 14:30:30 UTC
Pushed to v3-5-test.
Closing out bug report.

Thanks!