[Samba] ACLs under Samba 3.3.0

[Ryan B. Lynch]

Jeremy Allison wrote:
> 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 tested this about four weeks ago, comparing operations from Windows 
clients against our Samba 3.2.7 server and another machine running a 
3.3.0 pre-release checkout.  The ACL rights assignments did appear to be 
different, but I believe that the actual results were different, too.

That is to day, a Windows user could delete, rename, or take ownership 
of a file/directory on which that user had UNIX 'rwx' rights, but only 
on 3.2.7.  This didn't work on 3.3.0.

But I want to be careful before I say I'm sure, because you (Jeremy) 
certainly know this subject better than me.  I'm going to test those 
same operations over the weekend, and I'll confirm whether it's just a 
different appearance or whether it affects the actual operations.  I 
will also turn the debug logging up to the max, and I'll attach that to 
bug #6005 with an update.


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

For our users, it's a requirement--the business process requires one 
user to be able to rename, delete, etc. directory trees and files that 
other users create.

-Ryan

-- 

Ryan B. Lynch
Engineer
Innovative Discovery, LLC
http://www.id-edd.com/
347.633.0512
ryan.lynch at id-edd.com