[cifs-protocol] [EXTERNAL] [MS-DTYP] meaning of sign and base and range in conditional ACE integers - TrackingID#2212220040005997

Fri Jan 20 01:53:28 UTC 2023

The encoding is all int64. I was able to confirm this in the OS implementation today.

Regards,
Kristian

-----Original Message-----
From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz> 
Sent: Wednesday, January 18, 2023 6:59 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] meaning of sign and base and range in conditional ACE integers - TrackingID#2212220040005997

hi Kristian,

Does this bit of test code shed light on the question of whether a number can end up not being encoded as 64-bit, when parsed from SDDL?

Notwithstanding that, I think I have enough to go on for now.

Thank you for your help.

Douglas

On 19/01/23 07:31, Kristian Smith wrote:
> Hi Douglas,
> 
> Thanks for the clarification. You're right that 0xFFFF... is a -1.
> 
> I also found code that sheds some light on the situation. A test case for conditional ACE's encodes an SDDL string. Here is the pseudocode:
> 
> index = 0
> //look for  sign
> if (string[index] == '+')
> 	sign_byte = 0x1
> 	index++
> else if (string[index] == '-')
> 	sign_byte = 0x2
> 	index++
> else
> 	sign_byte = 0x3
> 
> //look for base
> if (string[index] == '0x')
> 	base_byte = 0x3
> 	index++
> else if (string[index] == '0')
> 	base_byte = 0x1
> 	index++
> else
> 	base_byte = 0x2
> 
> This provides confirmation that the base_byte and the sign_byte are used for SDDL rendering purposes. You'll also notice that "None" is the catch-all for there being no '+' or '-' in the first index.
> 
> I just submitted a document change request to add more clarity regarding the Sign and Base Bytes.
>   
> Let me know if you have any additional questions.
> 
> Thanks,
> Kristian
> 
> 
> 
> -----Original Message-----
> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> Sent: Friday, January 13, 2023 6:03 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] meaning of sign and base and range 
> in conditional ACE integers - TrackingID#2212220040005997
> 
> hi Kristian,
> 
> yeah, those are pretty much the issues.
> 
> One thing about the example:
> 
>>> 0x04 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x02 0x02 This takes a 
>>> 64-bit positive '1' and negates it with the 0x02 sign byte.
> 
> Actually, 0xFFFFFFFFFFFFFFFF is already -1 in twos complement, so the 0x02 doesn't negate the sign, rather it seems to confirm it.
> 
> I wonder is if this is for display purposes also. Supposing it had 
> 0x03
> ("hex") for base and 0x01 ("positive") for sign, this might be displayed as 0xFFF..., while if it had 0x2 for sign, it would be displayed as -0x000000000001.
> 
> In this interpretation, the maths is not affected, and 0x03 for sign 
> ("no
> sign") would just mean display it conventionally.
> 
> I note that example 2 in 2.4.4.17.9 uses a 64 bit value with "decimal" and "no sign" for a value written as "1" in the SDDL. There seems to be no way in SDDL to indicate the bit size of a literal integer. This answers the question I had about round-trips from ACE to SDDL to ACE: no, they won't always end up at the same ACE if the SDDL forgets the integer bit size.
> Maybe SDDL -> ACE -> SDDL is still on.
> 
> cheers,
> Douglas
> 
> 
> On 14/01/23 13:29, Kristian Smith wrote:
>> Hi Douglas,
>>
>> <Moving us to the other case thread>
>>
>> I've been looking into this one trying to make sense of the sign byte and base byte as well.
>>
>>
>> Sign byte:
>>
>> The signed int8 - signed int64 are setup with 2's complement. To my understanding the purpose of this is to represent negative and positive values. Adding the sign byte would negate the need for this (or vice versa). It appears that the sign byte is a sign override.
>>
>> I'm currently trying to determine if we are treating the 2's complement negative and positive numbers the same and just using the sign byte.
>>
>> In the example:
>>
>> Thus the decimal value -1 encoded as a signed int64 would have the following binary representation (byte code, QWORD, sign byte, base byte):
>>
>> 0x04 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x02 0x02 This takes a 
>> 64-bit positive '1' and negates it with the 0x02 sign byte.
>>
>>
>>
>> Base byte:
>>
>> I need to confirm this, but I believe you are correct that this is just for rendering purposes, as the math should be the same.
>>
>>
>>
>> Integer size:
>>
>> Since these are all represented by QWORDs, the size would just dictate what bytes to ignore (if any).
>>
>>
>>
>> What I need to determine:
>>
>> Does the "None" sign byte just treat the integer as positive? What's the difference between "None" and "Positive"?
>> Are negative and positive numbers treated the same and just overridden with the sign byte?
>> Is the Base byte just used to determine rendering, or does it somehow affect math/comparisons?
>>
>>
>> Let me know if we're on the same page.
>>
>>
>>
>> Regards,
>> Kristian
>>
>> From: Kristian Smith <Kristian.Smith at microsoft.com>
>> Sent: Thursday, December 29, 2022 12:17 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] meaning of sign and base and range 
>> in conditional ACE integers - TrackingID#2212220040005997
>>
>> Hi Douglas,
>>
>> I'll be looking into this issue as well. 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: Kristian Smith
>> <Kristian.Smith at microsoft.com<mailto:Kristian.Smith at microsoft.com>>
>> Sent: Thursday, December 22, 2022 9:19 AM
>> To: Douglas Bagnall
>> <douglas.bagnall at catalyst.net.nz<mailto:douglas.bagnall at catalyst.net.
>> n
>> z>>;
>> 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: Interoperability Documentation Help 
>> <dochelp at microsoft.com<mailto:dochelp at microsoft.com>>
>> Subject: Re: [EXTERNAL] [MS-DTYP] meaning of sign and base and range 
>> in conditional ACE integers - TrackingID#2212220040005997
>>
>> [DocHelp to Bcc]
>>
>> Hi Douglas,
>>
>> Thanks for reaching out to DocHelp regarding your [MS-DTYP] questions. I have created case 2212220040005997 so that we can look into these questions. An engineer will reach out soon.
>>
>> Thank you,
>> 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: Douglas Bagnall
>> <douglas.bagnall at catalyst.net.nz<mailto:douglas.bagnall at catalyst.net.
>> n
>> z>>
>> Sent: Wednesday, December 21, 2022 6:16 PM
>> To:
>> 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>>
>> ;
>> Interoperability Documentation Help
>> <dochelp at microsoft.com<mailto:dochelp at microsoft.com>>
>> Subject: [EXTERNAL] [MS-DTYP] meaning of sign and base and range in 
>> conditional ACE integers
>>
>> hi Dochelp,
>>
>> In MS-DTYP 2.4.4.17.5 literal integers are encoded as a 64 bit 
>> number, followed by a byte for sign and a byte for base. The range of 
>> the integer is indicated by the token bytecode.
>>
>> I don't understand how the sign and base are used.
>>
>> In the example at the bottom of section 2.4.4.17.5 a negative number 
>> is encoded with sign 'None' and base 10. What would be different in 
>> practice if it were encoded with a different base or sign? Would it 
>> compare differently?
>>
>> As far as I can tell, the only use of integer literal tokens is in 
>> binary relational operators. The documentation for these operators
>> (2.4.4.17.6) says things like
>>
>>> MUST evaluate to TRUE if the argument on the RHS evaluates to the 
>>> exact value (single or set value) of the argument on the LHS; otherwise, FALSE.
>>
>> but it doesn't define how the evaluation works with the sign, base, 
>> and range.
>>
>> In conventional mathematics octal 03 == decimal 3 == hex 0x03. Does 
>> this hold for conditional ACE literals?
>>
>> Also, in many systems, the 16 bit value '123' would equal the 32 bit 
>> values '123'. Does this hold in conditional ACEs?
>>
>> And the sign byte -- what is that for? Does -1 with a negative sign 
>> not equal -1 with a 'none' sign? and can -1 have a positive sign?
>>
>> Is the base just used for determining how the number is rendered when 
>> converted into SDDL?
>>
>> cheers,
>> Douglas
>>
> 