On Fri, Jan 30, 2009 at 03:35:24PM -0500, Ryan B. Lynch wrote: > Miguel Medalha wrote: >> >>> Much of the ACL code has been rewritten to allow underlying >>> filesystems to implement "native" NT ACLs directly (...) >> >> Good! >> >>> but the functionality should be the same as 3.2.x when not >>> using the "experimental" ACL modules. >>> >>> >> >> I am not using the ACL modules and the functionality is definitely NOT >> the same. My users complained immediately. > > > We've been working to implement Samba 3.3 at our site since December. We > saw the same behaviour that Miguel describes since RC2, and we see it > today in a test with the final 3.3.0 release. > > We opened a bug report, #6005, but we didn't have a chance to post the > debug logs that Volcker requested, and it's closed, now. We will > probably do that next week and reopen it. Here's the link: > https://bugzilla.samba.org/show_bug.cgi?id=6005 > > I would describe the problem *slightly* differently from Miguel. I do > not think that ACLs are the real problem, because the bug behaviour > exists regardless of whether you're using filesystem ACLs or not. > > The problem seems to be that the configuration option 'acl map full > control' isn't working anymore under 3.3. This option took me a long > time to understand, because it refers to Windows ACLs, not filesystem > ACLs. If the option is set (which is the default under both 3.2.7 and > 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' > rights under Windows. This is regardless of whether the 'rwx' > permissions come from the base UNIX permissions or POSIX ACLs. > > 3.2.7 works as the man page describes, but 3.3.0 does not. Under 3.3.0, > a user with 'rwx' will have every Windows right except for 'Delete' and > 'Full Control'. Even the file's owner will lack those two rights. > Nonetheless, the owner will be able to delete or rename the file, but > not any other users, even if they apparently have identical rights. > > Also, this behaviour seems to persist whether you explicitly turn 'acl > map full control' on or off. We also tried a few dozen combinations of > other permission, ownership, and ACL-related options in 'smb.conf', and > none of them worked.
Ok, here are the two commits that affected this issue to make it differ from 3.2.x. commit 51b5364c2afb3a18df4bec2bc1624760ccc01676 Author: Volker Lendecke <[email protected]> Date: Tue Jun 17 16:22:43 2008 +0200 RWX on a file does not imply DELETE access Without this the changed checks in can_delete_file_in_directory give DELETE access where there is none. So we can end up granting the ntcreate&x preparing the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED at close time later, which in turn does *not* give the access denied error message in the Windows GUI. can_delete_file_in_directory will grant access now by looking at the directory permissions. commit daa9b056645a45edfb3a70e3536011ebe5678970 Author: Volker Lendecke <[email protected]> Date: Thu Jun 19 14:53:46 2008 +0200 Fix checks in can_delete_file_in_directory() With at least NFSv4 ACLs around the write permission for the owner is a bogus check if we can delete a file in a directory. Like in Windows, there are two ways which can grant us such: First, the DELETE permission on the file itself, or if that does not help, the DELETE_CHILD permission on the directory. It might be a bit more code that runs, but essentially we should end up with the same set of syscalls in the non-acl case. This looks like a compatibility change to make us work better with NFSv4 underlying ACLs, not POSIX ones. I'll do some more digging. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
