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

[Bill Wesse]

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