Bug 8515 - Empty CIFS share can be blocked for other clients by deleting it via empty path (DELETE_PENDING until the last client)
Empty CIFS share can be blocked for other clients by deleting it via empty pa...
Product: Samba 3.5
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-10-10 10:28 UTC by Volodymyr Khomenko
Modified: 2011-11-14 17:37 UTC (History)
1 user (show)

See Also:

Test patch for 3.5.next. (698 bytes, patch)
2011-10-11 23:56 UTC, Jeremy Allison
no flags Details
Correct (fixed) patch of JeremyA for bug8515 (612 bytes, patch)
2011-10-12 09:48 UTC, Volodymyr Khomenko
no flags Details
git-am fix for 3.6.1 (1.33 KB, patch)
2011-10-12 19:19 UTC, Jeremy Allison
metze: review+
git-am fix for 3.5.x. (1.33 KB, patch)
2011-10-12 19:32 UTC, Jeremy Allison
metze: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Volodymyr Khomenko 2011-10-10 10:28:10 UTC

We have occasionally reproduced the following scenario:
1. A regular client was viewing CIFS share.
2. Admin client (with full access permissions) was deleting all content of the same share via Visual Basic script.
3. Due a mistake in the script, empty path was also used as the last step of deletion.  SMBrmdir request with empty path was sent to the server and the result was *successful*.
4. The first (regular) client was not able to work with the share any more due DELETE_PENDING errors.
5. The flow returned to normal when all CIFS clients closed their connections to the share. Share itself was NOT deleted.

Step4 is problematic here: CIFS share is blocked by regular CIFS request and cannot be accessed any more.

Debugging samba code gave following flow:
- Empty path for SMBrmdir request was mapped to '.' path inside samba.
- In the step3 Delete operation is done via opening the '.' directory and setting DELETE_ON_CLOSE flag for it (see reply_rmdir function). Access was granted, directory was marked for deletion, no special sanity checks was performed for the path.
- On the directory close actual deletion was not done while there is other client holding the same directory.
-In the step4 NTCreate operations by regular client for share directory fail because the directory is marked for deletion (until it will be closed by the last client).
-In step5 when the last client closes the handle of directory '.' and sees DELETE_ON_CLOSE flag, it actually tries to delete it. He proceed VFS layers and finally enters default implementation for VFS_rmdir (vfswrap_rmdir). rmdir(".") syscall is executed, but it fails with EINVAL error:

$ man 2 rmdir |grep EINVAL
EINVAL pathname has .  as last component.
In such way SMBclose fails with NT_STATUS_INVALID_PARAMETER and share directory is NOT deleted; DELETE_ON_CLOSE flag is not set any more, clients can work with the share again.

This is some kind of Deny-Of-Service issue. I propose to fix it by denying deletion of the share directory ('.'). The good place for the fix is can_set_delete_on_close() function: the share directory cannot be deleted.

Volodymyr Khomenko.
Comment 1 Jeremy Allison 2011-10-11 23:56:29 UTC
Created attachment 6987 [details]
Test patch for 3.5.next.

Can you check this patch against your reproducible test case please ?

If you can confirm this fixes the problem I'll create a git-am fix and get it into all active Samba branches.


Comment 2 Jeremy Allison 2011-10-11 23:57:09 UTC
FYI - thanks for your excellent description of the problem and pointing out the correct place to make a fix.
Comment 3 Volodymyr Khomenko 2011-10-12 09:48:36 UTC
Created attachment 6988 [details]
Correct (fixed) patch of JeremyA for bug8515

Jeremy did a small mistake in his patch: ISDOT() macro needs a pointer to char and not to struct smb_filename.
This is fixed patch for bug8515.
Comment 4 Volodymyr Khomenko 2011-10-12 09:51:50 UTC
(In reply to comment #1)
> Can you check this patch against your reproducible test case please ?

Jeremy, your original patch doesn't work because you've done a small mistake in it.
I've attached fixed patch-file; I confirm that it fixes our reproducible scenario (no DELETE_PENDING errors any more).

Thanks for support,
Volodymyr Khomenko.
Comment 5 Jeremy Allison 2011-10-12 16:03:18 UTC
Doh ! Thanks, that's what happens when you quickly add something without testing, sorry. It was a "test" patch after all :-).

Thanks for fixing it, I'll add the fix with your name (as you're the one who fixed it :-).


Comment 6 Jeremy Allison 2011-10-12 19:19:55 UTC
Created attachment 6990 [details]
git-am fix for 3.6.1

Fix that went into master.
Comment 7 Jeremy Allison 2011-10-12 19:32:20 UTC
Created attachment 6991 [details]
git-am fix for 3.5.x.
Comment 8 Stefan Metzmacher 2011-10-12 19:38:31 UTC
Comment on attachment 6990 [details]
git-am fix for 3.6.1

Looks good
Comment 9 Stefan Metzmacher 2011-10-12 19:39:28 UTC
Karolin, please pick for the release
Comment 10 Karolin Seeger 2011-10-12 19:51:44 UTC
Pushed to v3-5-test and v3-6-test.
Closing out bug report.

Comment 11 Stefan Metzmacher 2011-11-14 17:37:50 UTC
Comment on attachment 6991 [details]
git-am fix for 3.5.x.

Looks good