'Re: [cifs-protocol] [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#22121700400002'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [EXTERNAL] [MS-DTYP] conditional ACE SDDL sid arrays - TrackingID#22121700400002
From:       Douglas Bagnall via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date:       2023-01-20 2:48:49
Message-ID: a2e55561-9568-c829-9eb7-c19de3019992 () catalyst ! net ! nz
[Download RAW message or body]

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@catalyst.net.nz>
> Sent: Friday, January 13, 2023 3:28 PM
> To: Kristian Smith <Kristian.Smith@microsoft.com>; cifs-protocol@lists.samba.org
> Cc: Microsoft Support <supportmail@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@catalyst.net.nz>
> > Sent: Wednesday, January 11, 2023 10:33 PM
> > To: Kristian Smith <Kristian.Smith@microsoft.com>;
> > cifs-protocol@lists.samba.org
> > Cc: Microsoft Support <supportmail@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@catalyst.net.nz>
> > > Sent: Wednesday, January 11, 2023 3:13 PM
> > > To: Kristian Smith <Kristian.Smith@microsoft.com>;
> > > cifs-protocol@lists.samba.org
> > > Cc: Microsoft Support <supportmail@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@microsoft.com <mailto:kristian.smith@microsoft.com>
> > > > 
> > > > *From:* Kristian Smith <Kristian.Smith@microsoft.com>
> > > > *Sent:* Thursday, December 29, 2022 12:13 PM
> > > > *To:* Douglas Bagnall <douglas.bagnall@catalyst.net.nz>;
> > > > cifs-protocol@lists.samba.org
> > > > *Cc:* Microsoft Support <supportmail@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@microsoft.com <mailto:kristian.smith@microsoft.com>
> > > > 
> > > > --------------------------------------------------------------------
> > > > -
> > > > -
> > > > ----------
> > > > 
> > > > *From:*Jeff McCashland (He/him) <jeffm@microsoft.com
> > > > <mailto:jeffm@microsoft.com>>
> > > > *Sent:* Friday, December 16, 2022 8:17 PM
> > > > *To:* Douglas Bagnall <douglas.bagnall@catalyst.net.nz
> > > > <mailto:douglas.bagnall@catalyst.net.nz>>;
> > > > cifs-protocol@lists.samba.org <mailto:cifs-protocol@lists.samba.org>
> > > > <cifs-protocol@lists.samba.org
> > > > <mailto:cifs-protocol@lists.samba.org>>
> > > > *Cc:* Microsoft Support <supportmail@microsoft.com
> > > > <mailto:supportmail@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@catalyst.net.nz
> > > > <mailto:douglas.bagnall@catalyst.net.nz>>
> > > > Sent: Friday, December 16, 2022 6:02 PM
> > > > To: Interoperability Documentation Help <dochelp@microsoft.com
> > > > <mailto:dochelp@microsoft.com>>; cifs-protocol@lists.samba.org
> > > > <mailto:cifs-protocol@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
> > > > 
> > > 
> > 
> 

_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[prev in list] [next in list] [prev in thread] [next in thread] 