[cifs-protocol] [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#2212170040000207
Douglas Bagnall
douglas.bagnall at catalyst.net.nz
Fri Jan 20 02:48:49 UTC 2023
hi Kristian,
That is mostly what I was hoping would be the answer, and the proposed
documentation change looks sensible.
thanks,
Douglas
On 20/01/23 15:19, Kristian Smith wrote:
> Hi Douglas,
>
> Circling back to the first thread.
>
> In my research on this question, I was able to determine that the member-of operand indeed assumes it will be an array. This, however, only sets a flag to check that all inputs of a composite are typed the same.
>
> You should be able to use a literal SID in a member-of operand with or without braces"{}". This would just dictate whether or not you were using a composite.
>
> The whitespace is ignored, so it could potentially look strange as you stated: (Member_ofSID(BA))
> Note: That syntax *cannot* be an array based on my research as there is no looping function to gather all of the components like there is when using braces "{}".
>
> My suggested document change will be: remove "literal SID" option from a SID-array, and add a "literal-SID" option to "member_of" operand
>
> Hopefully this clears up the confusion. If not, please let me know.
>
> Thanks,
> Kristian
>
> -----Original Message-----
> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> Sent: Friday, January 13, 2023 3:28 PM
> To: Kristian Smith <Kristian.Smith at microsoft.com>; cifs-protocol at lists.samba.org
> Cc: Microsoft Support <supportmail at microsoft.com>
> Subject: Re: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#2212170040000207
>
> hi Kristian,
>
> Thanks. I am working on conditional aces, but there are lots of other bits I can concentrate on apart from the compiler for SDDL. So I am not exactly blocked, but may be at some point (case 2212220040005997 about integers is more baffling right now).
>
> Douglas
>
> On 14/01/23 11:48, Kristian Smith wrote:
>> Hi Douglas,
>>
>> I have submitted the document change request as the overlapping ABNF indeed requires more clarity. I will archive the case until I hear back from our engineering team with more information. If you are currently blocked from moving forward on your work without this information, please let me know.
>>
>> Thanks,
>> Kristian
>>
>> -----Original Message-----
>> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>> Sent: Wednesday, January 11, 2023 10:33 PM
>> To: Kristian Smith <Kristian.Smith at microsoft.com>;
>> cifs-protocol at lists.samba.org
>> Cc: Microsoft Support <supportmail at microsoft.com>
>> Subject: Re: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays -
>> TrackingID#2212170040000207
>>
>> hi Kristian,
>>
>> Right, understood regarding "hypothetical".
>>
>> As far as I can see, the encoding of a single SID as a member-of operand, rather than that of a composite list containing a single SID is not explained anywhere in the documentation. I think it should be.
>>
>> I also would like to highlight a point about ABNF syntax which may
>> have lead us to talk past each other a bit. The "[]" in "[wspace]"
>> makes it optional, meaning "zero or one of these", while a bare
>> "wspace" means "always one of these". So when you say
>>
>>>> Using a SID array with single element:
>>>> ("Member_of") [wspace] "SID(" sid-string ")" [wspace]
>>
>> that trailing "[wspace]" overlaps with the definition for
>>
>>>> Hypothetical, using single literal SID:
>>>> ("Member_of") [wspace] "SID(" sid-string ")"
>>
>> because "[wspace]" could mean zero white space characters.
>>
>>
>> Also, as I mentioned parenthetically at the start, this is not how
>> Member-of is defined in the ABNF. It is defined as
>>
>> memberof-op = ( "Member_of" / ... ) wspace sid-array
>>
>> with a *non-optional* wspace. However the example omits the wspace:
>>
>> (@User.clearanceLevel>=@Resource.requiredClearance) ||
>> (Member_of{SID(BA)})
>>
>> which, you know, looks fine when there's a "{" there. But I doubt whether "[wspace]" would work for the memberof-op definition if the line were written using this construct:
>>
>> (Member_ofSID(BA))
>>
>> which would supposedly be valid but looks annoying for the tokeniser. But I don't really care about that; I just assume the ABNF was written after the fact and is approximate. My original main question was:
>>
>>>>> so *syntactically*, this (a literal-SID without the curly brackets)
>>>>>
>>>>> (Member_of SID(BA))
>>>>>
>>>>> would also refer to a sid-array. Thus here's the question: would
>>>>> this last form be compiled as a composite value (as implied by
>>>>> "sid-array") or would it be a solitary SID?
>>>>>
>>>>> And if doesn't result in a solitary SID, how would such a SID be
>>>>> represented in SDDL, or is that not possible?
>>
>> and what you're saying is
>>
>> (Member_of SID(BA))
>>
>> *would* be encoded as a solitary SID, but
>>
>> (Member_of SID(BA) )
>>
>> might not be.
>>
>> Is that right?
>>
>> thanks
>> Douglas
>>
>>
>> On 12/01/23 16:31, Kristian Smith wrote:
>>> Hi Douglas,
>>>
>>> My apologies for the confusion. By hypothetical, I meant that this is what the "Member_of" structure would look like if it were built with just a literal-SID, of which it is not. I provided it for the sake of comparison to the structure when using a sid-array to highlight the [wspace].
>>>
>>> As far as explaining the difference between the single-element sid-array and a literal-SID, what information would be helpful to add?
>>>
>>> Also, if you have a reason to believe that Windows is not following this documentation, I'd be happy to look at a trace to see what's happening.
>>>
>>> Regards,
>>> Kristian
>>>
>>>
>>> -----Original Message-----
>>> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>>> Sent: Wednesday, January 11, 2023 3:13 PM
>>> To: Kristian Smith <Kristian.Smith at microsoft.com>;
>>> cifs-protocol at lists.samba.org
>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>> Subject: Re: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays -
>>> TrackingID#2212170040000207
>>>
>>> thanks Kristian,
>>>
>>> Just to clarify this bit
>>>
>>>> Hypothetical, using single literal SID: ("Member_of") [wspace] "SID(" sid-string ")"
>>>
>>> when you say "hypothetical", does that mean you haven't confirmed it?
>>>
>>> I don't have any problem with the example. The example is good! It would be nice to have more.
>>>
>>> I think the problem is with the ABNF, which does not make this distinction and has other inaccuracies, as noted earlier.
>>>
>>> If the absence of a whitespace token makes a difference to the parsing, the ABNF should not just say "[wspace]", it should explain the difference.
>>>
>>> cheers,
>>> Douglas
>>>
>>>
>>> On 12/01/23 11:10, Kristian Smith wrote:
>>>> Hi Douglas,
>>>>
>>>> After researching this [MS-DTYP] question, I've determined that the
>>>> difference between a sid-array and a literal-SID is a trailing [wspace].
>>>>
>>>> Here is my logic:
>>>>
>>>> Member_of general definition:
>>>> ("Member_of") [wspace] sid-array
>>>>
>>>> SID array general definition:
>>>> sid-array =[wspace] / "{" [wspace] literal-SID [wspace] *( ","
>>>> [wspace] literal-SID [wspace]) "}"
>>>>
>>>> SID array with single element:
>>>> sid-array = literal-SID [wspace]
>>>>
>>>> Alternate SID array with single element: sid-array = "{"
>>>> [wspace] literal-SID [wspace] "}"
>>>>
>>>> literal-SID = "SID(" sid-string ")"
>>>>
>>>> *Using a SID array with single element: ("Member_of")
>>>> [wspace] "SID(" sid-string ")" [wspace]*
>>>>
>>>> *Alt SID array with single element:
>>>> ("Member_of") [wspace] "{" [wspace] "SID(" sid-string ")" [wspace]
>>>> "}"*
>>>>
>>>> Hypothetical, using single literal SID:
>>>> ("Member_of") [wspace] "SID(" sid-string ")"
>>>>
>>>> The document dictates the use of a sid-array for "Member_of",
>>>> regardless of the number of elements in the array. This would mean
>>>> using curly braces with [wspace] padding, or using the trailing
>>>> [wspace], as bolded above. If you believe that example 3 needs to be
>>>> altered, please let me know what would enable better clarity.
>>>>
>>>> Thank you for your patience,
>>>>
>>>> Kristian
>>>>
>>>> Kristian Smith
>>>>
>>>> Support Escalation Engineer
>>>>
>>>> Windows Open Spec Protocols
>>>>
>>>> Office: (425) 421-4442
>>>>
>>>> kristian.smith at microsoft.com <mailto:kristian.smith at microsoft.com>
>>>>
>>>> *From:* Kristian Smith <Kristian.Smith at microsoft.com>
>>>> *Sent:* Thursday, December 29, 2022 12:13 PM
>>>> *To:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz>;
>>>> cifs-protocol at lists.samba.org
>>>> *Cc:* Microsoft Support <supportmail at microsoft.com>
>>>> *Subject:* Re: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays
>>>> -
>>>> TrackingID#2212170040000207
>>>>
>>>> Hi Douglas,
>>>>
>>>> I'll be looking into this issue for you. I'll reach out when I have
>>>> more information.
>>>>
>>>> Thanks,
>>>>
>>>> Kristian
>>>>
>>>> Kristian Smith
>>>>
>>>> Support Escalation Engineer
>>>>
>>>> Windows Open Spec Protocols
>>>>
>>>> Office: (425) 421-4442
>>>>
>>>> kristian.smith at microsoft.com <mailto:kristian.smith at microsoft.com>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> ----------
>>>>
>>>> *From:*Jeff McCashland (He/him) <jeffm at microsoft.com
>>>> <mailto:jeffm at microsoft.com>>
>>>> *Sent:* Friday, December 16, 2022 8:17 PM
>>>> *To:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz
>>>> <mailto:douglas.bagnall at catalyst.net.nz>>;
>>>> cifs-protocol at lists.samba.org <mailto:cifs-protocol at lists.samba.org>
>>>> <cifs-protocol at lists.samba.org
>>>> <mailto:cifs-protocol at lists.samba.org>>
>>>> *Cc:* Microsoft Support <supportmail at microsoft.com
>>>> <mailto:supportmail at microsoft.com>>
>>>> *Subject:* RE: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays
>>>> -
>>>> TrackingID#2212170040000207
>>>>
>>>> [DocHelp to BCC, support on CC, SR ID on Subject]
>>>>
>>>> Hi Douglas,
>>>>
>>>> Thank you for the question. We have created SR 2212170040000207 to
>>>> track this issue. One of our engineers will respond soon to assist.
>>>>
>>>> Best regards,
>>>> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
>>>> Protocol Open Specifications Team
>>>> 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:
>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
>>>> p%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C421f45322d6a4be
>>>> 594ac08daf5bdc4c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63809
>>>> 2492656372827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DljfsWEZX
>>>> ETFmanmeHvwY1pvG0AGmC8%2FLYTBjoc7XBw%3D&reserved=0
>>>> o%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C74d0d56b504d4a2
>>>> 4
>>>> 4b5108daf466ce3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638091
>>>> 0
>>>> 19635751870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>>>> M
>>>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lai4tsyRdSeW
>>>> W
>>>> nNUaJfqPVM%2FuE1EGYx4IofPeMR97lQ%3D&reserved=0
>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7CKristian.Smith%40mic
>>>> r
>>>> o
>>>> soft.com%7C6a87d40a3707454b63ab08daf42959a1%7C72f988bf86f141af91ab2d
>>>> 7
>>>> c
>>>> d011db47%7C1%7C0%7C638090755686769017%7CUnknown%7CTWFpbGZsb3d8eyJWIj
>>>> o
>>>> i
>>>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
>>>> %
>>>> 7
>>>> C%7C&sdata=zlPMuqt%2BofqxEUMjN6EmMT8n3xv1BIqjPgkmtFx8eHY%3D&reserved
>>>> =
>>>> 0
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsu
>>>> p%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C421f45322d6a4be
>>>> 594ac08daf5bdc4c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63809
>>>> 2492656372827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PnJFZ5gxi
>>>> cAo0%2FUAp7skacwLkDQadq0UsZ9%2B7NjG9Bo%3D&reserved=0
>>>> p%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C74d0d56b504d4a2
>>>> 4
>>>> 4b5108daf466ce3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638091
>>>> 0
>>>> 19635751870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>>>> M
>>>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qt0Am79V4mYd
>>>> 9
>>>> U2vy1kBzxEaYIbtioENnKI%2B2gUIl0M%3D&reserved=0
>>>> ort.microsoft.com%2Fglobalenglish&data=05%7C01%7CKristian.Smith%40mi
>>>> c
>>>> r
>>>> osoft.com%7C6a87d40a3707454b63ab08daf42959a1%7C72f988bf86f141af91ab2
>>>> d
>>>> 7
>>>> cd011db47%7C1%7C0%7C638090755686769017%7CUnknown%7CTWFpbGZsb3d8eyJWI
>>>> j
>>>> o
>>>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
>>>> C
>>>> %
>>>> 7C%7C&sdata=zlPMuqt%2BofqxEUMjN6EmMT8n3xv1BIqjPgkmtFx8eHY%3D&reserve
>>>> d
>>>> =
>>>> 0> | Extension 1138300
>>>>
>>>> -----Original Message-----
>>>> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz
>>>> <mailto:douglas.bagnall at catalyst.net.nz>>
>>>> Sent: Friday, December 16, 2022 6:02 PM
>>>> To: Interoperability Documentation Help <dochelp at microsoft.com
>>>> <mailto:dochelp at microsoft.com>>; cifs-protocol at lists.samba.org
>>>> <mailto:cifs-protocol at lists.samba.org>
>>>> Subject: [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays
>>>>
>>>> hi Dochelp,
>>>>
>>>> I am working on conditional ACES for Samba. The documentation is
>>>> mostly very clear, but I have one question prompted by example 3 in
>>>> 2.4.4.19, which deals with the encoding of this SDDL snippet:
>>>>
>>>> > (@User.clearanceLevel>=@Resource.requiredClearance
>>>> <mailto:=@Resource.requiredClearance>) || > (Member_of{SID(BA)})
>>>>
>>>> where the 'Member_of{SID(BA)}' becomes a composite token containing
>>>> the single SID, followed by the Member_of operator. So far this makes sense.
>>>>
>>>> However, earlier, in 2.4.4.17.6 ('Relational Operator Tokens') we
>>>> have
>>>>
>>>> > The operand type MUST be either a SID literal, or a composite,
>>>> each of > whose elements is a SID literal.
>>>>
>>>> which is also clear. But the ABNF in 2.5.1.1 ('Syntax') look like
>>>>
>>>> > memberof-op = ( "Member_of" / ... ) wspace sid-array
>>>>
>>>> and sid-array is
>>>>
>>>> > sid-array = literal-SID [wspace] / "{" [wspace] literal-SID [wspace] *( ","
>>>> [wspace] literal-SID [wspace]) "}"
>>>>
>>>> so *syntactically*, this (a literal-SID without the curly brackets)
>>>>
>>>> (Member_of SID(BA))
>>>>
>>>> would also refer to a sid-array. Thus here's the question: would
>>>> this last form be compiled as a composite value (as implied by
>>>> "sid-array") or would it be a solitary SID?
>>>>
>>>> And if doesn't result in a solitary SID, how would such a SID be
>>>> represented in SDDL, or is that not possible?
>>>>
>>>> The wider question is whether, for valid conditonal aces, an ACE ->
>>>> SDDL -> ACE cycle should always end up at the same point as the original.
>>>>
>>>> As a side-note, the example omits the wspace in memberof-op. I
>>>> suspect the ABNF is inexact, but it might be fiddly to fix because I don't know if '[wspace]'
>>>> would work for the form without {}.
>>>>
>>>> cheers,
>>>> Douglas
>>>>
>>>
>>
>
More information about the cifs-protocol
mailing list