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 > To: Nadezhda Ivanova > Cc: 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 > To: Nadezhda Ivanova > Cc: 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 > Offse
