[cifs-protocol] [MS-DTYP] conditional ACE SDDL sid arrays

Douglas Bagnall douglas.bagnall at catalyst.net.nz
Sat Dec 17 02:02:12 UTC 2022


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) || (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