[Samba] ACLs under Samba 3.3.0

[Jeremy Allison]

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 <vl at samba.org>
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 <vl at samba.org>
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.