Bug 3347 - Delete a file for DELETE_ON_CLOSE flag failed if user has no permission to delete
Summary: Delete a file for DELETE_ON_CLOSE flag failed if user has no permission to de...
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.21a
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 3467
  Show dependency tree / graph
 
Reported: 2005-12-22 00:11 UTC by SATOH Fumiyasu
Modified: 2014-11-13 13:52 UTC (History)
2 users (show)

See Also:

Attachments
patch: try to delete again with root privilege (2.56 KB, patch)
2006-01-12 01:48 UTC, SATOH Fumiyasu 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description SATOH Fumiyasu 2005-12-22 00:11:32 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.
Comment 1 SATOH Fumiyasu 2006-01-12 01:48:56 UTC 
Created attachment 1668 [details]
patch: try to delete again with root privilege
Comment 2 Jeremy Allison 2006-01-12 09:04:57 UTC 
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.
Thanks,
Jeremy.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2006-01-25 08:35:17 UTC 
This is fixed now right?
Comment 4 SATOH Fumiyasu 2006-01-25 09:43:08 UTC 
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?
Comment 5 Jeremy Allison 2006-01-25 10:24:31 UTC 
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....

Thanks,

Jeremy.
Comment 6 Jeremy Allison 2006-02-02 13:49:22 UTC 
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.
Thanks,
Jeremy.
Comment 7 Richard Sharpe 2013-04-20 23:27:35 UTC 
Hmmm, I am sure this bug is long fixed.

Can it be closed.
Comment 8 Volker Lendecke 2014-11-13 13:52:53 UTC 
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