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.
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.
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.
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?
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.
*** Bug 6812 has been marked as a duplicate of this bug. ***
This bug is fixed now, I believe, so it should be closed.