Access-Control Entries (ACEs)

An access-control list (ACL) contains zero or more access-control entries (ACEs) that control or monitor access to an object by a specified trustee. Each ACE contains the following access-control information:

A security identifier (SID) that identifies the trustee. A trustee can be a user account, group account, or a logon account for a program such as a Windows NT service.
An access mask that specifies the access rights controlled by the ACE.
A flag that indicates the type of ACE.
A set of bit flags that determine whether other containers or objects can inherit the ACE from the primary object to which the ACL is attached.

There are three types of ACEs currently supported by Windows NT. Windows NT does not currently support system-alarm ACEs.

Type	Description
Access-denied ACE	Used in a DACL to deny the specified access rights to the trustee.
Access-allowed ACE	Used in a DACL to grant the specified access rights to the trustee.
System-audit ACE	Used in a SACL to generate an audit record when the trustee attempts to exercise the specified access rights.

In a DACL, you should place any access-denied ACEs at the beginning of the list of ACEs in an ACL, ahead of any access-allowed ACEs. In determining whether to grant access to an object, the system checks an access token against the ACEs in the ACL. The system stops checking the ACEs when one of the following events occurs:

One or more access-allowed ACEs explicitly grant the necessary access rights to the trustee or to groups of which the trustee is a member.
An access-denied ACE explicitly denies the requested access rights.
All ACEs have been checked without granting the requested access, in which case, access is implicitly denied.

Positioning access-denied ACEs at the beginning of the ACL ensures that the specified trustee is denied access even if an access-allowed ACE in the list grants the access to the trustee or a group to which the trustee belongs.

If a trustee is a member of several groups represented by ACEs in the DACL, the rights granted to each group apply to the trustee. For example, a trustee may request read/write access to an object. Suppose one ACE in the list grants read access to a group. Another ACE grants write access to a different group. If the trustee belongs to both groups, the request for read/write access succeeds.

A SACL is useful when a system administrator wants to keep a log of attempts to access a secured object. A system-audit ACE can be set to generate an audit record when an access attempt by the trustee succeeds, fails, or both. The system enters the audit record in the system event log. An administrator can use the Event Viewer to examine entries in the event log. Applications can use the event-logging functions to access the event log.

ACEs and ACLs are opaque structures. Internally, they use the ACL, ACE_HEADER, ACCESS_ALLOWED_ACE, ACCESS_DENIED_ACE, and SYSTEM_AUDIT_ACE structures to store information. However, applications should not try to work directly with the contents of these structures. To ensure that ACLs are semantically correct, use the appropriate Win32 functions to create and manipulate ACLs and ACEs.

Software for developers: Delphi Components
.Net Components
Software for Android Developers
More information resources: MegaDetailed.Net
Unix Manual Pages
Delphi Examples
Databases for Amazon shops developers: Amazon Categories Database
Browse Nodes Database