As a result of a customer situation I have found that Windows will allow a CreateFile to succeed for what Samba calls OVERWRITE_IF, CREATE and OPEN_IF when the requester asks for DELETE_ON_CLOSE and DELETE access but does not have DELETE or DELETE_CHILD in the directory the file is being created in. However, in the case of OVERWRITE_IF and OPEN_IF, only allows the operation to succeed if the requested file does not exist. Otherwise it returns ACCESS_DENIED. Samba only allows this when CREATE is used. I believe that the following code is at fault: /* This is the correct thing to do (check every time) but can_delete * is expensive (it may have to read the parent directory * permissions). So for now we're not doing it unless we have a strong * hint the client is really going to delete this file. If the client * is forcing FILE_CREATE let the filesystem take care of the * permissions. */ /* Setting FILE_SHARE_DELETE is the hint. */ if ((create_disposition != FILE_CREATE) && (access_mask & DELETE_ACCESS) && (!(can_delete_file_in_directory(conn, smb_fname) || can_access_file_acl(conn, smb_fname, DELETE_ACCESS)))) { status = NT_STATUS_ACCESS_DENIED; DEBUG(10,("create_file_unixpath: open file %s " "for delete ACCESS_DENIED\n", smb_fname_str_dbg(smb_fname))); goto fail; } It should check the other two disposition values and defer the decision about needing can_delete_file_in_directory until we know whether or not the file exists. If have checked the master branch as well, and while the code has been moved around, and in particular the checking has now been deferred to can_set_delete_on_close, but that too does not allow it in the cases Windows would, I believe.
Created attachment 8729 [details] A test that demonstrates the difference This test demonstrates the difference. It is self contained. Here is the result against Windows: [rsharpe@rsharpe-centos63 samba.master]$ ./bin/smbtorture //192.168.56.50/testnodeletechild -Usomedom/administrator%some-pass smb2.delete-on-close-perms smbtorture 4.1.0pre1-DEVELOPERBUILD Using seed 1365120368 time: 2013-04-04 17:06:08.535864 progress: 3 test: OVERWRITE_IF time: 2013-04-04 17:06:08.560092 Create file with DeleteOnClose on non-existent file (OVERWRITE_IF) Creating Directory for testing: test_dir get the original sd Setting permissions on dir to 0x1e01bf Pausing to check. Press enter: time: 2013-04-04 17:06:38.938735 success: OVERWRITE_IF test: CREATE time: 2013-04-04 17:06:38.938815 Create file with DeleteOnClose on non-existent file (CREATE) time: 2013-04-04 17:06:39.011916 success: CREATE test: CREATE_IF time: 2013-04-04 17:06:39.011978 Create file with DeleteOnClose on non-existent file (OPEN_IF) Creating file for next test. Press enter to continue: time: 2013-04-04 17:07:01.782116 success: CREATE_IF Here is a run against Samba 3.6.12: [rsharpe@rsharpe-centos63 samba.master]$ ./bin/smbtorture //192.168.56.102/test1 -Usomedom/administrator%some-pass smb2.delete-on-close-perms smbtorture 4.1.0pre1-DEVELOPERBUILD Using seed 1365120764 time: 2013-04-04 17:12:44.497115 progress: 3 test: OVERWRITE_IF time: 2013-04-04 17:12:44.504657 Create file with DeleteOnClose on non-existent file (OVERWRITE_IF) Creating Directory for testing: test_dir get the original sd Setting permissions on dir to 0x1e01bf time: 2013-04-04 17:12:44.750999 failure: OVERWRITE_IF [ (../source4/torture/smb2/delete-on-close.c:126) Incorrect status NT_STATUS_ACCESS_DENIED - should be NT_STATUS_OK ] test: CREATE time: 2013-04-04 17:12:44.751061 Create file with DeleteOnClose on non-existent file (CREATE) Creating Directory for testing: test_dir get the original sd Setting permissions on dir to 0x1e01bf time: 2013-04-04 17:12:44.993507 success: CREATE test: CREATE_IF time: 2013-04-04 17:12:44.993667 Create file with DeleteOnClose on non-existent file (OPEN_IF) Creating Directory for testing: test_dir get the original sd Setting permissions on dir to 0x1e01bf time: 2013-04-04 17:12:45.144963 failure: CREATE_IF [ (../source4/torture/smb2/delete-on-close.c:186) Incorrect status NT_STATUS_ACCESS_DENIED - should be NT_STATUS_OK ]
*** Bug 9819 has been marked as a duplicate of this bug. ***