[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [EXTERNAL] [MS-DTYP] meaning of sign and base and range in conditional ACE integ
From: Kristian Smith via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date: 2023-01-20 1:53:28
Message-ID: DM6PR21MB15300F6E73873934CB6AFD5F95C59 () DM6PR21MB1530 ! namprd21 ! prod ! outlook ! com
[Download RAW message or body]
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@catalyst.net.nz>
Sent: Wednesday, January 18, 2023 6:59 PM
To: Kristian Smith <Kristian.Smith@microsoft.com>; cifs-protocol@lists.samba.org
Cc: Microsoft Support <supportmail@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@catalyst.net.nz>
> Sent: Friday, January 13, 2023 6:03 PM
> To: Kristian Smith <Kristian.Smith@microsoft.com>;
> cifs-protocol@lists.samba.org
> Cc: Microsoft Support <supportmail@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@microsoft.com>
> > Sent: Thursday, December 29, 2022 12:17 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] 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@microsoft.com<mailto:kristian.smith@microsoft.com>
> >
> >
> >
> > ________________________________
> > From: Kristian Smith
> > <Kristian.Smith@microsoft.com<mailto:Kristian.Smith@microsoft.com>>
> > Sent: Thursday, December 22, 2022 9:19 AM
> > To: Douglas Bagnall
> > <douglas.bagnall@catalyst.net.nz<mailto:douglas.bagnall@catalyst.net.
> > n
> > z>>;
> > cifs-protocol@lists.samba.org<mailto:cifs-protocol@lists.samba.org>
> > <cifs-protocol@lists.samba.org<mailto:cifs-protocol@lists.samba.org>>
> > Cc: Interoperability Documentation Help
> > <dochelp@microsoft.com<mailto:dochelp@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@microsoft.com<mailto:kristian.smith@microsoft.com>
> >
> >
> >
> > ________________________________
> > From: Douglas Bagnall
> > <douglas.bagnall@catalyst.net.nz<mailto:douglas.bagnall@catalyst.net.
> > n
> > z>>
> > Sent: Wednesday, December 21, 2022 6:16 PM
> > To:
> > cifs-protocol@lists.samba.org<mailto:cifs-protocol@lists.samba.org>
> > <cifs-protocol@lists.samba.org<mailto:cifs-protocol@lists.samba.org>>
> > ;
> > Interoperability Documentation Help
> > <dochelp@microsoft.com<mailto:dochelp@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
> >
>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic