Technology Summary for ACLs
This topic summarizes information about the managed API for discretionary access control lists (DACLs), system access control lists (SACLs), and access control entries (ACEs). You can use the classes in the System.Security.AccessControl namespace to programmatically access DACLs, SACLs, and ACEs for several types of protected resources in the .NET Framework version 2.0 and later.
The managed ACL API makes working with ACLs easier than the unmanaged implementation by providing several classes that take care of many details for you. For example, it is not possible to create null DACLs in the managed implementation and you no longer have to worry about accidentally creating an insecure DACL because of incorrectly ordering your ACEs.
Keywords
Access control list (ACL), discretionary access control list (DACL), system access control list (SACL), access control entry (ACE), audit ACE
Namespaces
Related Technologies
Security in the .NET Framework
Background
A discretionary access control list (DACL), which is sometimes abbreviated to ACL, is a mechanism used by Microsoft Windows NT and later to protect resources such as files and folders. DACLs contain multiple access control entries (ACEs) that associate a principal (usually a user account or group of accounts) with a rule that governs the use of the resource. DACLs and ACEs let you allow or deny rights to resources based on permissions that you can associate with user accounts. For example, you can create an ACE and apply it to the DACL of a file to bar anyone but an administrator from reading the file.
A system access control list (SACL), which is sometimes referred to as an audit ACE, is a mechanism that controls the audit messages associated with a resource. Similar to DACLs, SACLs contain ACEs that define the audit rules for a given resource. Audit ACEs allow you to record successful or failed attempts to access a resource, but differ from access ACEs because they do not govern which accounts can use a resource. For example, you can create an ACE and apply it to the SACL of a file to log all successful attempts to open the file.
ACL Classes at a Glance
The following table lists the main classes that you can use to easily create and modify ACLs for several technology areas. This is not a comprehensive list of the System.Security.AccessControl namespace, but rather a list of the primary classes that you should use to work with ACLs.
Technology area |
Classes |
|---|---|
Cryptographic keys |
|
Directories |
|
Event Wait handles |
|
Files |
|
Mutexes |
|
Registry keys |
|
Semaphores |
To query the existing ACL information for a resource or to apply modified ACL information to a resource, you must use one of several methods that provide access to the ACLs of an existing resource. The classes in the previous table provide methods to construct and edit ACLs but they do not provide ways to query or apply ACLs.
Every resource has associated methods that apply ACLs during resource creation (usually a constructor overload), that retrieve the ACLs for an existing resource, and that apply ACLs to an existing resource.
The following table lists the methods used to get and set ACLs for each technology area. These methods are located in several namespaces outside the System.Security.AccessControl namespace and are part of the high-level classes that represent a particular resource. For example, to query the ACLs for a specified directory, you use the Directory.GetAccessControl method to get the DirectorySecurity object that encapsulates the DACLs and SACLs for the directory. Note that some resources, such as files and directories, have several equivalent methods in different classes that provide access to ACLs.
Technology area |
Methods to get and set ACLs |
|---|---|
Cryptographic keys |
|
Directories |
DirectoryInfo.GetAccessControl |
Event Wait handles |
EventWaitHandle.GetAccessControl |
Files |
|
Mutexes |
|
Registry keys |
|
Semaphores |