The proposed extensibility of this bit array was as discussed with the product team during the coordinated development of the fixes.
However spec-by-phone-call is lossy (I'm actually pretty surprised we ended up so close!) but we are trying to pin things down firmly in the documents. Andrew Bartlett On Mon, 2021-11-29 at 18:49 +0000, Jeff McCashland (HE/HIM/THEY/THEM) via cifs-protocol wrote: > Hi Metze, > > How were you able to determine that the array size is > '((int)(flags_length/32))+1'? Do you have a trace or document > illustrating this? > > Also, it is expected that changes in the current Errata doc are not > included in the published document, but normally the changes would be > spelled out in the errata doc. > > Where did you find the Diff file with the changes? When I click the > link, I get a PDF download, but I can't tell where it's coming from. > > Best regards, > Jeff McCashland | 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: > http://support.microsoft.com/globalenglish | Extension 1138300 > We value your feedback. My manager is Natesha Morrison (namorri), +1 > (704) 430-4292 > > -----Original Message----- > From: Jeff McCashland > Sent: Wednesday, November 24, 2021 9:18 AM > To: metze <[email protected]>; Alexander Bokovoy <[email protected]> > Cc: [email protected] > Subject: RE: [EXTERNAL] [cifs-protocol] Update of MS-PAC spec > regarding November 2021 security updates - > TrackingID#2111240040005432 > > [Kristian to BCC] > > Hi Alexander and Metze, > > I will look into this and get back to you. > > Best regards, > Jeff McCashland | 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: http://support.microsoft.com/globalenglish | Extension 1138300 > We value your feedback. My manager is Natesha Morrison (namorri), +1 > (704) 430-4292 > > -----Original Message----- > From: Kristian Smith <[email protected]> > Sent: Wednesday, November 24, 2021 8:40 AM > To: metze <[email protected]>; Alexander Bokovoy <[email protected]> > Cc: [email protected] > Subject: RE:[EXTERNAL] [cifs-protocol] Update of MS-PAC spec > regarding November 2021 security updates - > TrackingID#2111240040005432 > > [DocHelp to Bcc] > > Hi Alexander and Metze, > > Thank you for your request. The case number 2111240040005432 has been > created for this inquiry. One of our team members will follow-up with > you soon. > > Regards, > Kristian > > Kristian Smith > Support Escalation Engineer > Windows Open Spec Protocols > Office: (425) 421-4442 > [email protected] > > > > -----Original Message----- > From: metze <[email protected]> > Sent: Wednesday, November 24, 2021 2:13 AM > To: Alexander Bokovoy <[email protected]>; Interoperability Documentation > Help <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Re: [cifs-protocol] Update of MS-PAC spec > regarding November 2021 security updates > > > Am 24.11.21 um 10:33 schrieb Alexander Bokovoy via cifs-protocol: > > Hello dochelp, > > > > I can see inconsistency in what is published on > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms- > > pac%2F& > > ;data=04%7C01%7CKristian.Smith%40microsoft.com%7C976b8182b4b84582f4 > > bd0 > > 8d9af334186%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377334569 > > 597 > > 45681%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > CJB > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7gzSojo9ov6Uwx80K%2FwOQ > > GhB > > drb8oxqR%2F7yid5vn8tQ%3D&reserved=0 > > with regards to the changes introduced as a part of the Microsoft > > Windows security update of November 2021. Could this inconsistency > > be > > clarified by publishing the new revision of the MS-PAC document? > > > > Errata document[1] talks about changes dated 2021/11/11 post V22.0 > > but > > the rest of the linked documents are only V22.0. > > > > In particular, the errata document[1] is saying: > > > > ----- > > The following sections were changed or added. Please see the diff > > document for the details. > > > > In section 2.10 UPN_DNS_INFO, added four new fields and a flag to > > the > > UPN_DNS_INFO structure. > > > > In section 2.14 PAC_ATTRIBUTES_INFO, added section. > > > > In section 2.15 PAC_REQUESTOR, added section. > > ----- > > > > The document published, however, does not have these changes. The > > last > > section in chapter 2 is '14', there is no section 2.15. > > I'm seeing it here: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwinprotocoldoc.blob.core.windows.net%2Fproductionwindowsarchives%2FMS-PAC%2F%255bMS-PAC%255d-20211109-diff.pdf&data=04%7C01%7Cjeffm%40microsoft.com%7Cd3b94f30d63a4201ca5708d9af6911a4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637733688085851057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=afpiUM0iw8uPezHr32JH3UVlG3HQcUD%2BnGteWfO%2FyEY%3D&reserved=0 > > But for me the PAC_ATTRIBUTES_INFO documentation is a bit unclear: > > We have this in Samba: > typedef [bitmap32bit] bitmap { > PAC_ATTRIBUTE_FLAG_PAC_WAS_REQUESTED = 0x00000001, > PAC_ATTRIBUTE_FLAG_PAC_WAS_GIVEN_IMPLICITLY = > 0x00000002 > } PAC_ATTRIBUTE_INFO_FLAGS; > > typedef struct { > uint32 flags_length; /* length in bits */ > PAC_ATTRIBUTE_INFO_FLAGS flags; > } PAC_ATTRIBUTES_INFO; > > And the documentation has: > > FlagsLength (4 bytes): An unsigned 32-bit integer in little-endian > format that describes the length, > in bits, of the Flags field. > > Flags (variable): an array of 32-bit unsigned integers in little- > endian format that contains flag bits > describing the PAC. > > It's not really clear that the array size is > '((int)(flags_length/32))+1', for now it's seems to be just a single > uint32 element with two defined flags. Unless bit 33 will be defined > someday, it would be easier to have it as > > typedef struct { > uint32 number_of_valid_flags; > uint32 flags; > } PAC_ATTRIBUTES_INFO; > > which is basically what we currently have in Samba, but in theory it > would have to be > > typedef struct { > uint32 number_of_valid_flags; > uint32 flags[(number_of_valid_flags/32)+1]; > } PAC_ATTRIBUTES_INFO; > > metze > > _______________________________________________ > cifs-protocol mailing list > [email protected] > https://lists.samba.org/mailman/listinfo/cifs-protocol -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba Samba Development and Support, Catalyst IT - Expert Open Source Solutions _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
