Bug 9821 - Inheritance of Object ACEs is broken in Master, 4.0, 3.6 and 3.5
Summary: Inheritance of Object ACEs is broken in Master, 4.0, 3.6 and 3.5
Status: ASSIGNED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Richard Sharpe
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-21 15:51 UTC by Richard Sharpe
Modified: 2015-07-31 08:25 UTC (History)
2 users (show)

See Also:


Attachments
A two packet capture showing the inheitable Object ACE (2.02 KB, application/octet-stream)
2013-04-21 15:53 UTC, Richard Sharpe
no flags Details
A two packet capture showing the result after inheritance (852 bytes, application/octet-stream)
2013-04-21 15:54 UTC, Richard Sharpe
no flags Details
A possible fix for this problem (18.89 KB, patch)
2013-04-21 16:00 UTC, Richard Sharpe
no flags Details
Showing setting the Obj Allow ACE and creation and bad SD. (6.76 KB, application/octet-stream)
2013-04-24 01:50 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 2013-04-21 15:51:10 UTC
I have come across a case where an application seems to be apply an inheritable OBJECT ALLOW ACE to a directory/container. When that ACE is inherited, it gets broken and Windows does not like any such SD that is retrieved.

Attached are two capture showing the inheritable ACE being applied and the result being retrieved.
Comment 1 Richard Sharpe 2013-04-21 15:53:02 UTC
Created attachment 8798 [details]
A two packet capture showing the inheitable Object ACE
Comment 2 Richard Sharpe 2013-04-21 15:54:56 UTC
Created attachment 8799 [details]
A two packet capture showing the result after inheritance
Comment 3 Richard Sharpe 2013-04-21 15:59:33 UTC
The problem is in se_create_child_secdesc and init_sec_ace, I believe.

In se_create_child_secdesc we do:

                init_sec_ace(new_ace, ptrustee, ace->type,
                             ace->access_mask, new_flags |
                                (set_inherited_flags ? SEC_ACE_FLAG_INHERITED_ACE : 0));


however, there is no way to pass in the object container if one exists in the ACE.

Attached is a patch that touches lots of files that might be a solution for this.

It is against 3.5.x so it will likely not apply to 4.0 or Master but might apply against 3.6.x.

I have not yet tested it because I don't have a torture test to set this up. I am waiting for my contact to test the patch I supplied.
Comment 4 Richard Sharpe 2013-04-21 16:00:33 UTC
Created attachment 8800 [details]
A possible fix for this problem
Comment 5 Richard Sharpe 2013-04-21 17:41:43 UTC
There might also be an additional issue here:

Perhaps I am mistaken, but my reading of the following from
librpc/idl/security.idl:

        typedef struct {
                security_ace_object_flags flags;
                [switch_is(flags & SEC_ACE_OBJECT_TYPE_PRESENT)]
security_ace_object_type type;
                [switch_is(flags &
SEC_ACE_INHERITED_OBJECT_TYPE_PRESENT)]
security_ace_object_inherited_type inherited_type;
        } security_ace_object;

suggests that the secuity_ace_object_type and
security_ace_object_inherited_type GUIDS will only be
marshalled/unmarshalled if the appropriate bits are set.

However, my reading of [MS-DTYP].PDF, section 2.4.4.3 suggest that
those fields are present on the wire regardless of the bit values and
the flags field only serves to tell us whether those fields are valid.
Comment 6 Richard Sharpe 2013-04-24 01:39:13 UTC
OK, I have a capture that shows that on-the-wire a GUID in an object ACE that is not valid is not there either. 

Do, the IDL is correct.

Secondly, I have reproduced this against Samba 3.6.12.

Here is what a DOS prompt shows:

Z:\testagain>icacls file.txt
file.txt: The specified server cannot perform the requested operation.
Successfully processed 0 files; Failed processing 1 files


I will attach a capture showing the SD being set on the parent directory.
Comment 7 Richard Sharpe 2013-04-24 01:50:28 UTC
Created attachment 8808 [details]
Showing setting the Obj Allow ACE and creation and bad SD.

This shows setting the SD with an Obj Inherit ACE, followed by creation of a file and then retrieving the SD. Windows does not like the SD that was created on inheritance.
Comment 8 Richard Sharpe 2013-04-24 16:44:57 UTC
The DACL was created with this SDDL:

D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO)

However, icacls will not add that DACL to a file.

You have to do it with a program that converts that SDDL to a DACL and then writes it directly to the file.

My contact gave me such a program.
Comment 9 Stefan Metzmacher 2013-04-25 06:24:08 UTC
(In reply to comment #8)
> The DACL was created with this SDDL:
> 
> D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO)
> 
> However, icacls will not add that DACL to a file.
> 
> You have to do it with a program that converts that SDDL to a DACL and then
> writes it directly to the file.
> 
> My contact gave me such a program.

Does a windows server allows such a DACL?
I thought only the SMB server would only allow SECURITY_ACL_REVISION_NT4
ACLs which don't allow object allow aces.
Comment 10 Richard Sharpe 2013-04-25 14:01:29 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > The DACL was created with this SDDL:
> > 
> > D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO)
> > 
> > However, icacls will not add that DACL to a file.
> > 
> > You have to do it with a program that converts that SDDL to a DACL and then
> > writes it directly to the file.
> > 
> > My contact gave me such a program.
> 
> Does a windows server allows such a DACL?
> I thought only the SMB server would only allow SECURITY_ACL_REVISION_NT4
> ACLs which don't allow object allow aces.

That is a good question. I don't know but will test in a day or so.

Somehow a Windows client running CommVault set the DACL as I have a capture showing it.

I suspect that it was due to an unusual DACL that it found on the folder, though.
Comment 11 Karolin Seeger 2013-12-10 15:51:25 UTC
Any news on this one?
Comment 12 Andreas Schneider 2014-10-28 10:48:48 UTC
Assigning to Richard!
Comment 13 Karolin Seeger 2014-11-25 19:32:42 UTC
ping