[cifs-protocol] [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#2212170040000207
Kristian Smith
Kristian.Smith at microsoft.com
Thu Jan 12 18:41:15 UTC 2023
I was quite sure that I was missing something, and indeed I was. Thank you for clarifying my wspace confusion.
I will submit a document change request based on this overlapping definition of a single-element sid-array and literal-SID as well as the inconsistency between the "Member_of" ABNF definition with the example.
Is this ABNF discontinuity currently a blocking issue to your work, or are you just hoping to get consistency in the document?
Regards,
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