[Samba] ACLs under Samba 3.3.0

[Jeremy Allison]

On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote:
> > 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.

Volker's changes are correct, in that delete access in POSIX does not
belong to a file itself, but to the containing directory. So really
we should remove the DELETE_ACCESS bit from both the file and the
directory ACL returned. This unfortunately breaks the fiction of
a rwx permission mapping directly into Windows FULL_CONTROL. What
your users can do with the file over Samba hasn't actually changed,
is they have write access to the directory they can still delete
the file, but the ACLs "look funny".

I'll think some more about how we can restore the fiction for
the users without having to use the experimental native ACL
store.

Jeremy.