Bug 8963 - vfa_acl_common.c does the wrong thing when there are no inheritable ACEs in parent ACL on creating a new file/folder
vfa_acl_common.c does the wrong thing when there are no inheritable ACEs in p...
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules
unspecified
All All
: P5 normal
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 17:21 UTC by Richard Sharpe
Modified: 2017-10-25 09:12 UTC (History)
2 users (show)

See Also:


Attachments
A patch that addresses this issue (1.82 KB, patch)
2012-05-30 18:09 UTC, Richard Sharpe
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Sharpe 2012-05-30 17:21:56 UTC
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 :-)
Comment 1 Richard Sharpe 2012-05-30 18:09:31 UTC
Created attachment 7608 [details]
A patch that addresses this issue

Here is a patch that I think addresses this issue.
Comment 2 Jeremy Allison 2012-05-30 19:29:43 UTC
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.
Comment 3 Richard Sharpe 2012-05-30 20:03:14 UTC
(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.
Comment 4 Ralph Böhme 2017-10-25 09:12:01 UTC
This should be fixed in later Samba releases.