[cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)

[Bill Wesse]

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.ivanova at postpath.com] 
Sent: Wednesday, November 18, 2009 11:50 AM
To: Bill Wesse
Cc: cifs-protocol at 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 <billwe at microsoft.com>
> To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> Cc: cifs-protocol at samba.org <cifs-protocol at 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-protocols at 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.ivanova at postpath.com] 
> Sent: Wednesday, November 18, 2009 6:26 AM
> To: Interoperability Documentation Help
> Cc: cifs-protocols at 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