The code in source3/modules/vfs_acl_common.c:inherit new acl does the wrong thing if there are no inheritable components on the ACL in the directory the new object is being created in _and_ we do not have "inherit owner = yes" set on the share. It currently does not even set an SD on the new object, by the look of things: if (!inheritable_components && !inherit_owner) { /* Nothing to inherit and not setting owner. */ return NT_STATUS_OK; } However, on Windows (at least W2K08R2) when there are no inheritable components on a directory and you create a new object it creates an SD with a two-element DACL where the creator gets FULL access and SYSTEM gets full access. For example, if Administrator (in the joined domain) creates the file: REVISION:1 CONTROL:0x8404 OWNER:BUILTIN\Administrators GROUP:TESTAD\Domain Admins ACL:BUILTIN\Administrators:ALLOWED/0x0/FULL ACL:NT AUTHORITY\SYSTEM:ALLOWED/0x0/FULL If an ordinary user creates the file: REVISION:1 CONTROL:0x8404 OWNER:TESTAD\mtest1 GROUP:TESTAD\Domain Users ACL:TESTAD\mtest1:ALLOWED/0x0/FULL ACL:NT AUTHORITY\SYSTEM:ALLOWED/0x0/FULL Now, we have a known issue where we do not transform Administrator to BUILTIN\Administrators, but other than that we should do the correct thing, it seems to me. I will attach a patch that I believe fixes the problem, however, it might not be the most elegant patch :-)
Created attachment 7608 [details] A patch that addresses this issue Here is a patch that I think addresses this issue.
Ok, the original idea was that if there was no inheritable components then we just defer to the underlying filesystem ACL. But if we're going for 100% Windows ACL compatibility, then this makes sense. Let's push into master first, then decide about applicability to 3.6.x. Deal ? Jeremy.
(In reply to comment #2) > Ok, the original idea was that if there was no inheritable components then we > just defer to the underlying filesystem ACL. > > But if we're going for 100% Windows ACL compatibility, then this makes sense. > > Let's push into master first, then decide about applicability to 3.6.x. > > Deal ? Hmmm, actually, I suspect that we should introduce another dreaded parameter, perhaps one like acl_xattr:emulate_windows = yes | NO ... Other than that I think your proposal is fine. I will rework the patch.
This should be fixed in later Samba releases.
this isn't fixed and we really need to address this. It is also an issue with acl_xattr but exspecially with filesystems supporting native NFS4 ACLs this is causing unintended permission headaches. Generally what Richard's patch intends to do is what Samba should do by default, a parametric option isn't even needed for this becasue leaving the permission settings up to the OS is just plain wrong.