[Samba] ACLs under Samba 3.3.0

John H Terpstra jht at samba.org
Fri Jan 30 22:13:18 GMT 2009

On Friday 30 January 2009 15:53:08 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'll think some more about how we can restore the fiction for
> the users without having to use the experimental native ACL
> store.
> Jeremy.


Ryan's environment requires that users have full control over all files in a 
directory.  So long as they have read and write access (in the directory and 
for the file) they must be able to delete the file and/or rename it, even 
where it belongs to another user.  We have not be been able to get this to 
work with 3.3.0.  It is working without any problems with 3.2.7.  It does 
appear that something has changed in 3.3.0 compared with 3.2.7.

Ryan is using 3.3.0 so that he can use CTDB.  We are in the process of 
rebuilding the clustered environment and will be able to test the full 
combination some time next week.  Right now we are running tests with 
samba-3.3.0 without using CTDB but using binaries that have it enabled.

Site operators don't really care what the Full Control flags look like, so 
long as they can delete files that were created by another user.

John T.
John H Terpstra

"If at first you don't succeed, don't go sky-diving!"

More information about the samba mailing list