Hi Douglas, Could you let us know a bit more about how this relates to what you're working on?
It appears to me that the documentation sufficiently covers your question #3. We document that inherited ACEs must be kept in the order they are inherited. Since each parent orders their explicit ACEs before their inherited ACEs, the ACEs are already in canonical order coming from the parent. The directive to maintain the order in which they were inherited means they need to be kept in the same order coming from the parent. This will preserve the parent/grandparent ordering without needing to identify which ACEs come from the parent and which come from the grandparent. Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 ________________________________ From: Jeff McCashland (He/him) <je...@microsoft.com> Sent: Wednesday, May 8, 2024 11:11 AM To: Douglas Bagnall <douglas.bagn...@catalyst.net.nz> Cc: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>; Sreekanth Nadendla <srena...@microsoft.com> Subject: Re: [MS-DTYP] canonical ACL sort order Q3 - TrackingID#2405080040008240 Hi Douglas, I will research your question and let you know what I find. Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 ________________________________ From: Sreekanth Nadendla <srena...@microsoft.com> Sent: Wednesday, May 8, 2024 8:51 AM To: Douglas Bagnall <douglas.bagn...@catalyst.net.nz> Cc: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org> Subject: [MS-DTYP] canonical ACL sort order Q3 - TrackingID#2405080040008240 Dochelp in Bcc Hello Douglas, this e-mail thread will be used to track the investigation for the following issue ISSUE: MS-DTYP definition says little about the ordering of DENY and ALLOW ACEs in the inherited sections. In places where canonical ACLs are constructed, such as https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378695121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CBrpNXxW1LpEgR2JCm5L6R0YLhld1DYAkYC8dFX43LE%3D&reserved=0 > The following steps describe the preferred order: > > 1. All explicit ACEs are placed in a group before any inherited ACEs. > > 2. Within the group of explicit ACEs, access-denied ACEs are placed before > access-allowed ACEs. > > 3. Inherited ACEs are placed in the order in which they are inherited. ACEs > inherited from the child object's parent come first, then ACEs inherited > from > the grandparent, and so on up the tree of objects. > > 4. For each level of inherited ACEs, access-denied ACEs are placed before > access-allowed ACEs. the inherited ACEs are placed in stripes like of DENY and ALLOW ACEs, like tree rings. This is not part of the definition in MS-DTYP, which only says "inherited ACEs are placed in the order in which they were inherited". Should it be part of MS-DTYP 2.4.5? Of course, when looking at a DACL in isolation, there is no way of knowing where the inherited ACEs were inherited from, so the question is kind of moot. Maybe that is why MS-DTYP doesn't want to say much, and why the MS-ADTS algorithm just flattens the inheritance, potentially changing the outcome (by bringing a grandparent DENY in front of a parent ALLOW). Regards, Sreekanth Nadendla Microsoft Windows Open Specifications ________________________________ From: Douglas Bagnall <douglas.bagn...@catalyst.net.nz> Sent: Tuesday, May 7, 2024 8:11 PM To: Interoperability Documentation Help <doch...@microsoft.com>; cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org> Subject: [EXTERNAL] [MS-DTYP] canonical ACL sort order hi Dochelp. I have questions about the definition of the canonical ACL form, to do with the status of callback ACEs and the ordering of inherited ACEs. MS-DTYP 2.4.5 says: > An ACL is said to be in canonical form if: > > * All explicit ACEs are placed before inherited ACEs. > > * Within the explicit ACEs, deny ACEs come before grant ACEs. > > * Deny ACEs on the object come before deny ACEs on a child or property. > > * Grant ACEs on the object come before grant ACEs on a child or property. > > * Inherited ACEs are placed in the order in which they were inherited. I think the third and fourth clauses are talking about the OBJECT ACE types, saying that e.g. ACCESS_ALLOWED_OBJECT_ACE_TYPE comes after ACCESS_ALLOWED_ACE_TYPE. But is it also talking about ACEs with the INHERIT_ONLY_ACE flag? Or some other mechanism? Logically it would seem that callback ACEs should be placed is a similar position to the OBJECT ones. Relevantly, MS-ADTS 6.1.3.1 says: > ACE ordering rules apply only to ACLs in canonical form (see [MS-DTYP] > section 2.4.5), and only when the forest functional level is > DS_BEHAVIOR_WIN2003 or above. The following rules are applied, in the > following order: > > 1. Explicit ACEs come before inherited ACEs. > > 2. Deny ACEs come before Allow ACEs. > > 3. Regular ACEs come before object ACEs. > > 4. Within each group, the ACEs are ordered lexicographically (that is, based > on > octet string comparison rules). > > Rules 3 and 4 above are enforced only when the forest functional level is > DS_BEHAVIOR_WIN2003 or above. Otherwise, the order of ACEs within each group > defined by rules 1 and 2 is retained as supplied by the user or replication > partner. Point 4 (sorting "lexicographically" via binary comparison), would sort the ACE structures primarily by ACE type, followed by flags, followed by the type specific members (often the SID is next). That would put the DENY ACEs in this order: ACCESS_DENIED_ACE_TYPE (1) ACCESS_DENIED_OBJECT_ACE_TYPE (6) ACCESS_DENIED_CALLBACK_ACE_TYPE (10) ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12) and similarly for the ALLOW ACEs. But by rule 3, we already have put "regular" ACEs before object ACEs, so if callback ACEs count as regular, we'd end up with ACCESS_DENIED_ACE_TYPE (1) ACCESS_DENIED_CALLBACK_ACE_TYPE (10) ACCESS_DENIED_OBJECT_ACE_TYPE (6) ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12) Are one of these orderings considered to be part of the canonical form? Either would be consistent with my understanding of MS-DTYP 2.4.5 with respect to plain and object ACEs. (As far as I can tell, the ordering within a block of DENY or ALLOW ACEs doesn't matter with respect to the eventual outcome, but putting the fancy kinds at the back is likely to be more efficient as it might avoid the extra work they entail). Also I note the MS-DTYP definition says little about the ordering of DENY and ALLOW ACEs in the inherited sections. In places where canonical ACLs are constructed, such as https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378695121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CBrpNXxW1LpEgR2JCm5L6R0YLhld1DYAkYC8dFX43LE%3D&reserved=0<https://learn.microsoft.com/en-us/windows/win32/SecAuthZ/order-of-aces-in-a-dacl> > The following steps describe the preferred order: > > 1. All explicit ACEs are placed in a group before any inherited ACEs. > > 2. Within the group of explicit ACEs, access-denied ACEs are placed before > access-allowed ACEs. > > 3. Inherited ACEs are placed in the order in which they are inherited. ACEs > inherited from the child object's parent come first, then ACEs inherited > from > the grandparent, and so on up the tree of objects. > > 4. For each level of inherited ACEs, access-denied ACEs are placed before > access-allowed ACEs. the inherited ACEs are placed in stripes like of DENY and ALLOW ACEs, like tree rings. This is not part of the definition in MS-DTYP, which only says "inherited ACEs are placed in the order in which they were inherited". Should it be part of MS-DTYP 2.4.5? Of course, when looking at a DACL in isolation, there is no way of knowing where the inherited ACEs were inherited from, so the question is kind of moot. Maybe that is why MS-DTYP doesn't want to say much, and why the MS-ADTS algorithm just flattens the inheritance, potentially changing the outcome (by bringing a grandparent DENY in front of a parent ALLOW). I'll note there are a wide range of formulations of canonicity, from Microsoft and elsewhere, not all of which can be compatible. For example, https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.security.accesscontrol.commonacl%3Fview%3Dnet-8.0&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378701549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pfebzEmURR5OTZQD%2B1JkZVW1KzYXj%2BmJO%2BVe%2Fvt3Rzc%3D&reserved=0<https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonacl?view=net-8.0> would not sort the ACEs lexicographically, but by SID. Do SACLs have a canonical ordering, beyond having explicit ACEs first? cheers, Douglas
_______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
