Re: [cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)
Hello Nadya - here are the results of my investigation. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. If you wish, I will keep the case open until the TDI has been resolved. The 'Sacl, Dacl, OwnerSid, GroupSid' data instance order you are seeing in the Windows self relative SECURITY_DESCRIPTOR is due to the Win API function 'MakeSelfRelativeSD' implementation, which emits them in that order. 'MakeAbsoluteSD' is order agnostic. This is why both [MS-DTYP] and MSDN define the SECURITY_DESCRIPTOR structure as opaque (references below). Given this, I expect that any SECURITY_DESCRIPTOR API functions should not make any assumptions concerning the appearance order of the target fields. Hence, I assert that both absolute and self-relative SECURITY_DESCRIPTOR pointer target fields should be assumed to be in no particular order. I have filed a TDI proposing clarification of this point in [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR. References: [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR http://msdn.microsoft.com/en-us/library/cc230366.aspx The self-relative form of the security descriptor is required if one wants to transmit the SECURITY_DESCRIPTOR structure as an opaque data structure for transmission in communication protocols over a wire, or for storage on secondary media; the absolute form cannot be transmitted because it contains pointers to objects that are generally not accessible to the recipient. SECURITY_DESCRIPTOR Structure http://msdn.microsoft.com/en-us/library/aa379561(VS.85).aspx Because the internal format of a security descriptor can vary, we recommend that applications not modify the SECURITY_DESCRIPTOR structure directly. For creating and manipulating a security descriptor, use the functions listed in See Also. See Also: GetSecurityDescriptorControl GetSecurityDescriptorDacl GetSecurityDescriptorGroup GetSecurityDescriptorLength GetSecurityDescriptorOwner GetSecurityDescriptorRMControl GetSecurityDescriptorSacl InitializeSecurityDescriptor IsValidSecurityDescriptor SetSecurityDescriptorDacl SetSecurityDescriptorGroup SetSecurityDescriptorOwner SetSecurityDescriptorRMControl SetSecurityDescriptorSacl Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Wednesday, November 18, 2009 7:57 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Good morning Nadya! I will begin work on this for you this morning. I have created the below case: SRX091118600013 [MS-DTYP] 2.4.6 self relative form of SECURITY_DESCRIPTOR Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, November 18, 2009 6:26 AM To: Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: Question about self relative form of SECURITY_DESCRIPTOR Hello, In MS-DTYP, section 2.4.6 (the table on page 55), the self relative format of a security descriptor is described as follows: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl OwnerSid GroupSid Sacl Dacl However, what we receive from the wire from a Win2003 or Win2008 is in fact in the form: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl Sacl Dacl OwnerSid GroupSid Although it does not prevent parsing the security descriptor, on a binary level the encoding between Windows and Samba is different, because Samba's is as documented. Is this the desired behavior or something that will be fixed? Best Regards, Nadezhda Ivanova ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)
Hi Bill, Thank you, this answers my question. I supposed that the order is indeed irrelevant as long as the offsets are correct, just wanted to double-check because of the explicit ordering in MS-DTYP. Regards, Nadya - Original Message - From: Bill Wesse bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: cifs-proto...@samba.org cifs-proto...@samba.org Sent: Wednesday, November 18, 2009 6:46:18 PM GMT+0200 Europe;Athens Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Hello Nadya - here are the results of my investigation. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. If you wish, I will keep the case open until the TDI has been resolved. The 'Sacl, Dacl, OwnerSid, GroupSid' data instance order you are seeing in the Windows self relative SECURITY_DESCRIPTOR is due to the Win API function 'MakeSelfRelativeSD' implementation, which emits them in that order. 'MakeAbsoluteSD' is order agnostic. This is why both [MS-DTYP] and MSDN define the SECURITY_DESCRIPTOR structure as opaque (references below). Given this, I expect that any SECURITY_DESCRIPTOR API functions should not make any assumptions concerning the appearance order of the target fields. Hence, I assert that both absolute and self-relative SECURITY_DESCRIPTOR pointer target fields should be assumed to be in no particular order. I have filed a TDI proposing clarification of this point in [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR. References: [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR http://msdn.microsoft.com/en-us/library/cc230366.aspx The self-relative form of the security descriptor is required if one wants to transmit the SECURITY_DESCRIPTOR structure as an opaque data structure for transmission in communication protocols over a wire, or for storage on secondary media; the absolute form cannot be transmitted because it contains pointers to objects that are generally not accessible to the recipient. SECURITY_DESCRIPTOR Structure http://msdn.microsoft.com/en-us/library/aa379561(VS.85).aspx Because the internal format of a security descriptor can vary, we recommend that applications not modify the SECURITY_DESCRIPTOR structure directly. For creating and manipulating a security descriptor, use the functions listed in See Also. See Also: GetSecurityDescriptorControl GetSecurityDescriptorDacl GetSecurityDescriptorGroup GetSecurityDescriptorLength GetSecurityDescriptorOwner GetSecurityDescriptorRMControl GetSecurityDescriptorSacl InitializeSecurityDescriptor IsValidSecurityDescriptor SetSecurityDescriptorDacl SetSecurityDescriptorGroup SetSecurityDescriptorOwner SetSecurityDescriptorRMControl SetSecurityDescriptorSacl Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Wednesday, November 18, 2009 7:57 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Good morning Nadya! I will begin work on this for you this morning. I have created the below case: SRX091118600013 [MS-DTYP] 2.4.6 self relative form of SECURITY_DESCRIPTOR Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, November 18, 2009 6:26 AM To: Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: Question about self relative form of SECURITY_DESCRIPTOR Hello, In MS-DTYP, section 2.4.6 (the table on page 55), the self relative format of a security descriptor is described as follows: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl OwnerSid GroupSid Sacl Dacl However, what we receive from the wire from a Win2003 or Win2008 is in fact in the form: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl Sacl Dacl OwnerSid GroupSid Although it does not prevent parsing the security descriptor, on a binary level the encoding between Windows and Samba is different, because Samba's is as documented. Is this the desired behavior or something that will be fixed? Best Regards, Nadezhda Ivanova ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)
As always, you are very welcome. Glad to have been of assistance! Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, November 18, 2009 11:50 AM To: Bill Wesse Cc: cifs-proto...@samba.org Subject: Re: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Hi Bill, Thank you, this answers my question. I supposed that the order is indeed irrelevant as long as the offsets are correct, just wanted to double-check because of the explicit ordering in MS-DTYP. Regards, Nadya - Original Message - From: Bill Wesse bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: cifs-proto...@samba.org cifs-proto...@samba.org Sent: Wednesday, November 18, 2009 6:46:18 PM GMT+0200 Europe;Athens Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Hello Nadya - here are the results of my investigation. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. If you wish, I will keep the case open until the TDI has been resolved. The 'Sacl, Dacl, OwnerSid, GroupSid' data instance order you are seeing in the Windows self relative SECURITY_DESCRIPTOR is due to the Win API function 'MakeSelfRelativeSD' implementation, which emits them in that order. 'MakeAbsoluteSD' is order agnostic. This is why both [MS-DTYP] and MSDN define the SECURITY_DESCRIPTOR structure as opaque (references below). Given this, I expect that any SECURITY_DESCRIPTOR API functions should not make any assumptions concerning the appearance order of the target fields. Hence, I assert that both absolute and self-relative SECURITY_DESCRIPTOR pointer target fields should be assumed to be in no particular order. I have filed a TDI proposing clarification of this point in [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR. References: [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR http://msdn.microsoft.com/en-us/library/cc230366.aspx The self-relative form of the security descriptor is required if one wants to transmit the SECURITY_DESCRIPTOR structure as an opaque data structure for transmission in communication protocols over a wire, or for storage on secondary media; the absolute form cannot be transmitted because it contains pointers to objects that are generally not accessible to the recipient. SECURITY_DESCRIPTOR Structure http://msdn.microsoft.com/en-us/library/aa379561(VS.85).aspx Because the internal format of a security descriptor can vary, we recommend that applications not modify the SECURITY_DESCRIPTOR structure directly. For creating and manipulating a security descriptor, use the functions listed in See Also. See Also: GetSecurityDescriptorControl GetSecurityDescriptorDacl GetSecurityDescriptorGroup GetSecurityDescriptorLength GetSecurityDescriptorOwner GetSecurityDescriptorRMControl GetSecurityDescriptorSacl InitializeSecurityDescriptor IsValidSecurityDescriptor SetSecurityDescriptorDacl SetSecurityDescriptorGroup SetSecurityDescriptorOwner SetSecurityDescriptorRMControl SetSecurityDescriptorSacl Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Wednesday, November 18, 2009 7:57 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Good morning Nadya! I will begin work on this for you this morning. I have created the below case: SRX091118600013 [MS-DTYP] 2.4.6 self relative form of SECURITY_DESCRIPTOR Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, November 18, 2009 6:26 AM To: Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: Question about self relative form of SECURITY_DESCRIPTOR Hello, In MS-DTYP, section 2.4.6 (the table on page 55), the self relative format of a security descriptor is described as follows: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl OwnerSid GroupSid Sacl Dacl However, what we receive from the wire from a Win2003 or Win2008 is in fact in the form: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl Sacl Dacl
