Permissions incorrectly ordered on Windows after disabling inheritance

[Walkes, Dan]

Richard and Andrew, thanks very much for your responses.  I've responded
inline below

On Sun, Aug 26, 2012 at 16:52:05, Richard Sharpe wrote:
> On Sun, Aug 26, 2012 at 3:21 PM, Andrew Bartlett <abartlet at samba.org>
> wrote:
> > On Sun, 2012-08-26 at 10:51 -0700, Richard Sharpe wrote:
> >> I have seen similar problems to this before, in the 3.5.x
vfs_acl_xattr stuff.
> >>
> >> Can you get a packet capture of the step where it all goes wrong? 

I've captured a series of traces at
ftp://ftp.tandbergdata.com/pub/samba/Traces/ and spent a bit of time
analyzing.  I captured one trace to correspond to each of the steps in
my repro steps listed in the first e-mail.  As far as "where it all goes
wrong" I'm not sure I know exactly - however here's my understanding
based on review of the traces and some reading of the CIFS spec at
http://msdn.microsoft.com/en-us/library/ee442092(v=prot.13).aspx 
1) In the step4 trace at Frame 1840 Windows resets security on
rootfolder\subfolder1 to force the "I" flag on all permissions entries:
---
Frame 1840: 358 bytes on wire (2864 bits), 358 bytes captured (2864
bits)
    Arrival Time: Aug 27, 2012 10:56:30.561976000 Mountain Daylight Time
...
        NT SET SECURITY DESC Parameters
            FID: 0x3c53 (\rootfolder\subfolder1)
                [Opened in: 1823]
                [Closed in: 1844]
...
                NT User (DACL) ACL
                    Revision: NT4 (2)
                    Size: 140
                    Num ACEs: 5
                    NT ACE:
S-1-5-21-3273740905-2057686771-3188122883-1000  (Domain SID-Domain RID),
flags 0x10, Access Allowed, mask 0x001f01bf
                        Type: Access Allowed (0)
                        NT ACE Flags: 0x10 Inherited ACE
...
                    NT ACE: S-1-3-0  (Creator Owner), flags 0x1b, Access
Allowed, mask 0x001f01bf
                        Type: Access Allowed (0)
                        NT ACE Flags: 0x1b Inherited ACE, Inherit Only,
Container Inherit, Object Inherit
...
                    NT ACE:
S-1-5-21-3273740905-2057686771-3188122883-513  (Domain SID-Domain
Users), flags 0x10, Access Allowed, mask 0x001f01bf
                        Type: Access Allowed (0)
                        NT ACE Flags: 0x10 Inherited ACE
---
All ACE's are marked as inherited with 0x10 flag set by Windows
including Creator Owner.  I believe S-1-5-21-XXX-1000  =user admin and
S-1-5-21-XXX-513  =group NONE weren't actually inherited but were
created through CREATOR OWNER and CREATOR GROUP ACE's which were
inherited. 

2) In the step5 trace - Frame 664 Create AndX Request for FID 0x3C69
path: \rootfolder\subfolder1\New Folder
The Create AndX Request doesn't include ACE's that I can see - and I
can't find this explicitly stated in the protocol documents, but I'm
assuming the samba server is filling in the default ACE's based on
inheritance?  Therefore I don't see the details in the wireshark trace
but I suspect the folder is created by samba with ACE for user admin and
group NONE not inherited (0x10 flag cleared) as would be expected since
the permissions were created based on CREATOR OWNER and not inherited.
However the ACE entries remain in the same order as the parent folder
and the Inherited flag remains set set on Creator Owner ACE.  This means
S-1-5-21-XXX-1000  =user admin remains ahead of ACE: S-1-3-0  (Creator
Owner) in the ACE list despite the fact that 0x10 is cleared on the user
admin ACE, resulting in an incorrect ordering message.

> >> It would be useful to see the ordering of the ACEs in the SD that 
> >> is being set and to see if acl_xattr is adding additional ACEs in 
> >> the wrong order.

My guess is that acl_xattr is replacing ACE's for user admin and group
NONE in their current position within the ACL, clearing 0x10 "I" flag
since these weren't inherited but added based on CREATOR OWNER, and not
modifying order of ACE's to account for the setting of the 0x10 inherit
flag on the CREATOR OWNER ACE.  

The problem could also be related to the fact that the 0x10 "I" flag
never appears to be set by samba even when setting permissions based on
inheritance.  Instead the "I" flags appear to always be copied from the
root folder directly, meaning the I flag would only be set if the root
folder's I flag was set for a specific ACE.  It appears OI|CI|IO|I flags
are always set based on the parent folder setting with samba.  In the
windows server case I believe OI|CI|IO are copied and the I flag is
always set when the corresponding ACE is there due to inheritance from
the parent (regardless of the parent setting of the "I" flag).  I
suspect if samba set the "I" flag on permissions which were in inherited
AND ordered all permissions such that permissions with the I flag set
were at the end of the ACL the behavior would match the windows server
CIFS implementation and there would be no more warnings about incorrect
ordering.  I'm new to samba/CIFS details though so I might be missing
something.

> > Richard and Dan,
> >
> > It would be really, really useful to get this into a unit test.  
> > I've created a scheme that will allow this locally in:
> > source4/scripting/python/samba/tests/ntacls.py
> 
> Once I get a capture I can look at the problem, and then try to add a 
> unit test for this case to ntacls.py

Thanks again for looking at this.  Let me know if there's anything else
I can do to help.