Bug 6892 - When a chown operation is issued via Windows Explorer, all ACLS are wiped out
Summary: When a chown operation is issued via Windows Explorer, all ACLS are wiped out
Status: ASSIGNED
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.4.1
Hardware: Other Windows XP
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
: 6812 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-12 02:24 UTC by Barry Sabsevitz (mail address dead)
Modified: 2011-10-30 18:22 UTC (History)
2 users (show)

See Also:


Attachments
Patch for 3.5.0 and master (2.14 KB, patch)
2009-11-20 19:32 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Sabsevitz (mail address dead) 2009-11-12 02:24:14 UTC
When we use Windows Explorer to change ownership on a file or folder, and use the acl_xattr module, all ACLs are wiped out. The reason for this is that Windows sends the security descriptor with dacl = NULL when it requests an owner or group change. But since the acl_xattr module writes out it's ACLs as a blob, it writes out a dacl = NULL to the xattr on the file system. This causes our ACLs to be wiped out. 

What I think the code needs to do when DACL information is not passed in to the set acl call is:
1. Issue a VFS_SMB_GET_NT_ACL call and ask for the DACL information and store in a temporary security descriptor (tmpsd).
2. Verify that psd->dacl is NULL and set psd->dacl = tmpsd->dacl;
3. Do normal set acl call which will set the owner or group change PLUS the DACL's that were originally on the file.
4. Free memory of tmpsd and set psd->dacl = NULL;

To reproduce:
1. Create a folder as user 1.
2. Create an ACL on folder to give user 2 full access rights.
3. As user 2: use Windows Explorer to change ownership of the folder from user 1 to user 2.
4. Check for Windows ACLs and you will see they are not there anymore.
Comment 1 Jeremy Allison 2009-11-20 19:32:15 UTC
Created attachment 4973 [details]
Patch for 3.5.0 and master

Ok, here is an (untested) fix for this for master and 3.5.0. It should be easy to back-port to 3.4.x. I'll test it here and commit when I'm satisfied. If you could do the same that would be very helpful !
Thanks,
Jeremy.
Comment 2 Barry Sabsevitz (mail address dead) 2009-11-20 20:28:01 UTC
Hi Jeremy, I don't think I'll be able to validate this fix. The code is pretty different in 3.4.1 than 3.5 and due to an internal scheduling issue, we cut our own patch for this. Our patch is different than yours but I think it is functionally close. The 3.4.1 code doesn't have a routine called get_nt_acl_internal(). We put code in that is likely not as complete as your fix but solved our immediate problem. We didn't address the fact that security information may also have to be read in but we fixed the issue where DACLs do.
Comment 3 Barry Sabsevitz (mail address dead) 2009-11-20 20:32:27 UTC
One quick comment: I didn't look at samba 3.5 source but the code:
status = get_nt_acl_internal(handle, fsp,
+				NULL,
+				(OWNER_SECURITY_INFORMATION|
+				 GROUP_SECURITY_INFORMATION|
+				 DACL_SECURITY_INFORMATION),
+				&nc_psd);


Do we need to free the memory for nc_psd when this routine is done? In 3.4.1, the call to SMB_VFS_GET_NT_ACL requires the memory to be freed, is get_nt_acl_internal() similar on 3.5?
Comment 4 Jeremy Allison 2009-11-25 12:23:19 UTC
Ok, tested here and merged into master and 3.5.0. I'll investigate a back-port for 3.4.x. To answer your question, we're not leaking memory here as the ACL is talloc'ed off the talloc TOS, which will get freed on exit from this specific SMB processing.
Jeremy.
Comment 5 Jeremy Allison 2009-11-25 17:23:04 UTC
*** Bug 6812 has been marked as a duplicate of this bug. ***
Comment 6 Richard Sharpe 2011-10-30 18:22:20 UTC
This bug is fixed now, I believe, so it should be closed.