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 > 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