<div class="content" name="ACL" uuid="20233ed8-a6c6-4097-aafa-dd545ed24428"><p>The access control list (ACL) packet is used to specify a
list of individual access control entries (<a href="d06e5a81-176e-46c6-9cf7-9137aad4455e" data-linktype="relative-path">ACEs</a>). An ACL packet and
an array of ACEs comprise a complete access control list.</p><p>The individual ACEs in an ACL are numbered from 0 to n,
where n+1 is the number of ACEs in the ACL. When editing an ACL, an application
refers to an ACE within the ACL by the ACE index.</p><p>In the absence of implementation-specific functions to
access the individual ACEs, access to each ACE MUST be computed by using the <b>AclSize</b>
and <b>AceCount</b> fields to parse the wire packets following the ACL to
identify each <a href="628ebb1d-c509-4ea0-a10f-77ef97ca4586" data-linktype="relative-path">ACE_HEADER</a>,
which in turn contains the information needed to obtain the specific ACEs.</p><p>An ACL is said to be in canonical form if:</p><ul><li><p><span><span> 
</span></span>All explicit ACEs are placed before inherited ACEs.</p>
</li><li><p><span><span> 
</span></span>Within the explicit ACEs, deny ACEs come before grant ACEs.</p>
</li><li><p><span><span> 
</span></span>Deny ACEs on the object come before deny ACEs on a child or
property.</p>
</li><li><p><span><span> 
</span></span>Grant ACEs on the object come before grant ACEs on a child or
property.</p>
</li><li><p><span><span> 
</span></span>Inherited ACEs are placed in the order in which they were
inherited.</p>
</li></ul><p>There are two types of ACL:</p><ul><li><p><span><span> 
</span></span>A <a href="a66edeb1-52a0-4d64-a93b-2f5c833d7d92#gt_d727f612-7a45-48e4-9d87-71735d62b321" data-linktype="relative-path">discretionary
access control list (DACL)</a> is controlled by the owner of an object or
anyone granted WRITE_DAC access to the object. It specifies the access
particular users and groups can have to an object. For example, the owner of a
file can use a DACL to control which users and groups can and cannot have
access to the file.</p>
</li><li><p><span><span> 
</span></span>A <a href="a66edeb1-52a0-4d64-a93b-2f5c833d7d92#gt_c189801e-3752-4715-88f4-17804dad5782" data-linktype="relative-path">system
access control list (SACL)</a> is similar to the DACL, except that the SACL is
used to audit rather than control access to an object. When an audited action
occurs, the operating system records the event in the security log. Each ACE in
a SACL has a header that indicates whether auditing is triggered by success,
failure, or both; a SID that specifies a particular user or security group to
monitor; and an access mask that lists the operations to audit.</p>
<p>The SACL also MAY contain<a id="Appendix_A_Target_71"></a><a aria-label="Product behavior note 71" href="11e1608c-6169-4fbc-9c33-373fc9b224f4#Appendix_A_71" data-linktype="relative-path">&lt;71&gt;</a> a label ACE that defines the
integrity level of the object.</p>
<p>The only valid ACE types
for a SACL are the auditing types (SYSTEM_AUDIT_ACE_TYPE,
SYSTEM_AUDIT_OBJECT_ACE_TYPE, SYSTEM_AUDIT_CALLBACK_ACE_TYPE, and
SYSTEM_AUDIT_CALLBACK_OBJECT_ACE_TYPE), the label type
(SYSTEM_MANDATORY_LABEL_ACE_TYPE), the system resource attribute type
(SYSTEM_RESOURCE_ATTRIBUTE_ACE_TYPE), and the scoped policy type
(SYSTEM_SCOPED_POLICY_ID_ACE_TYPE), as specified in section 2.4.4.1.</p>
<p>The SACL MUST NOT contain
ACEs that belong in the DACL, and the DACL MUST NOT contain ACE types that
belong in the SACL. Doing so results in unspecified behavior.</p>
</li></ul><table>
 <tbody><tr>
  <th><p><br/>0</p></th>
  <th><p><br/>1</p></th>
  <th><p><br/>2</p></th>
  <th><p><br/>3</p></th>
  <th><p><br/>4</p></th>
  <th><p><br/>5</p></th>
  <th><p><br/>6</p></th>
  <th><p><br/>7</p></th>
  <th><p><br/>8</p></th>
  <th><p><br/>9</p></th>
  <th><p>1<br/>0</p></th>
  <th><p><br/>1</p></th>
  <th><p><br/>2</p></th>
  <th><p><br/>3</p></th>
  <th><p><br/>4</p></th>
  <th><p><br/>5</p></th>
  <th><p><br/>6</p></th>
  <th><p><br/>7</p></th>
  <th><p><br/>8</p></th>
  <th><p><br/>9</p></th>
  <th><p>2<br/>0</p></th>
  <th><p><br/>1</p></th>
  <th><p><br/>2</p></th>
  <th><p><br/>3</p></th>
  <th><p><br/>4</p></th>
  <th><p><br/>5</p></th>
  <th><p><br/>6</p></th>
  <th><p><br/>7</p></th>
  <th><p><br/>8</p></th>
  <th><p><br/>9</p></th>
  <th><p>3<br/>0</p></th>
  <th><p><br/>1</p></th>
 </tr>
 <tr>
  <td colspan="8">AclRevision</td>
  <td colspan="8">Sbz1</td>
  <td colspan="16">AclSize</td>
 </tr>
 <tr>
  <td colspan="16">AceCount</td>
  <td colspan="16">Sbz2</td>
 </tr>
</tbody></table><p><b>AclRevision (1 byte): </b>An unsigned 8-bit value
that specifies the revision of the ACL. The only two legitimate forms of ACLs
supported for on-the-wire management or manipulation are type 2 and type 4. No
other form is valid for manipulation on the wire. Therefore this field MUST be
set to one of the following values.</p><dl>
<dd>
<table><thead>
  <tr>
   <th>
   <p>Value</p>
   </th>
   <th>
   <p>Meaning</p>
   </th>
  </tr>
 </thead><tbody><tr>
  <td>ACL_REVISION 0x02</td>
  <td>When set to 0x02, only AceTypes 0x00, 0x01, 0x02, 0x03, 0x11, 0x12, and 0x13 can be present in the ACL. An AceType of 0x11 is used for SACLs but not for DACLs. For more information about ACE types, see section 2.4.4.1.</td>
 </tr><tr>
  <td>ACL_REVISION_DS 0x04</td>
  <td>When set to 0x04, AceTypes 0x05, 0x06, 0x07, 0x08, and 0x11 are allowed. ACLs of revision 0x04 are applicable only to directory service objects. An AceType of 0x11 is used for SACLs but not for DACLs.</td>
 </tr></tbody></table>
</dd></dl><p><b>Sbz1 (1 byte): </b>An unsigned 8-bit value. This
field is reserved and MUST be set to zero.</p><p><b>AclSize (2 bytes): </b>An unsigned 16-bit integer
that specifies the size, in bytes, of the complete ACL, including all ACEs.</p><p><b>AceCount (2 bytes): </b>An unsigned 16-bit integer
that specifies the count of the number of ACE records in the ACL.</p><p><b>Sbz2 (2 bytes): </b>An unsigned 16-bit integer.
This field is reserved and MUST be set to zero.</p></div>