The Samba-Bugzilla – Bug 3347
Delete a file for DELETE_ON_CLOSE flag failed if user has no permission to delete
Last modified: 2014-11-13 13:52:53 UTC
When the file with DELETE_ON_CLOSE flag is closed by a user who
has no delete permission, delete operation is failed because
permission denied error.
User X has permission to delete the file F.
User Y has no permission to delete the file F.
1. User X: Open the file F with read/write mode and DELETE_ON_CLOSE flag.
2. User Y: Open the file F with read-only mode.
3. User X: Close the file F.
4. User Y: Close the file F. Try to delete the file F, but failed.
Created attachment 1668 [details]
patch: try to delete again with root privilege
I am very loath to add this patch without a config option explicitly allowing this. The problem is that as a POSIX application we can only detect if a file *may* be deleted. We only *know* if we can delete by doing it. This means that setting delete on close is only an advisory option for us. As we're not in the kernel as the Windows CIFS server is we can't guarentee that allowing a delete on close bit set means delete is allowed. I already discussed this with Volker - there are cases like AFS etc. where we simply can't know if this is allowed or not. Becoming root and doing this may have disasterous effects (symlink races causing security problems etc.).
This needs wider discussion. I really appreciate the work on the patch though.
This is fixed now right?
I think that Samba should save the user's uid and gid(s) on set
DELETE_ON_CLOSE flag, and use it on delete on close. Does Samba
have a temporary storage (tdb?) for that?
Actually Fumiyasu-san you just hit the nail on the head ! That is indeed the completely correct solution. Now the only question is how difficult that is to code up. It's complicated as it means passing a complete uid/gid-list token around. I need to think about this a while. This bug is not yet closed....
I have just committed what I hope is a correct bugfix for this.
Please check out SAMBA_3_0 or HEAD and test if this fixes the problem.
Hmmm, I am sure this bug is long fixed.
Can it be closed.
This particular one is long fixed with a "delete on close token". smbd now does switch to the credentials of the user who set the del on close flag when closing the file