[cifs-protocol] [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#2212170040000207
Douglas Bagnall
douglas.bagnall at catalyst.net.nz
Fri Jan 13 23:27:35 UTC 2023
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%2Fsupp
>>> o%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C74d0d56b504d4a24
>>> 4b5108daf466ce3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6380910
>>> 19635751870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lai4tsyRdSeWW
>>> nNUaJfqPVM%2FuE1EGYx4IofPeMR97lQ%3D&reserved=0
>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7CKristian.Smith%40micr
>>> o
>>> soft.com%7C6a87d40a3707454b63ab08daf42959a1%7C72f988bf86f141af91ab2d7
>>> c
>>> d011db47%7C1%7C0%7C638090755686769017%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
>>> i
>>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
>>> 7
>>> C%7C&sdata=zlPMuqt%2BofqxEUMjN6EmMT8n3xv1BIqjPgkmtFx8eHY%3D&reserved=
>>> 0
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
>>> p%2F&data=05%7C01%7CKristian.Smith%40microsoft.com%7C74d0d56b504d4a24
>>> 4b5108daf466ce3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6380910
>>> 19635751870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qt0Am79V4mYd9
>>> U2vy1kBzxEaYIbtioENnKI%2B2gUIl0M%3D&reserved=0
>>> ort.microsoft.com%2Fglobalenglish&data=05%7C01%7CKristian.Smith%40mic
>>> r
>>> osoft.com%7C6a87d40a3707454b63ab08daf42959a1%7C72f988bf86f141af91ab2d
>>> 7
>>> cd011db47%7C1%7C0%7C638090755686769017%7CUnknown%7CTWFpbGZsb3d8eyJWIj
>>> o
>>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
>>> %
>>> 7C%7C&sdata=zlPMuqt%2BofqxEUMjN6EmMT8n3xv1BIqjPgkmtFx8eHY%3D&reserved
>>> =
>>> 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