Please note: this short review is my own point of view on ACL and its usage. The aim of this review is to present basic information that you will probably need if you are going to manipulate Windows NT Security. Please refer to the Microsoft's documentation for the complete documentation about ACL.

Well, let's begin.

The ACL (Access Control List) is a variable length structure that is used to allow or deny access to securable object and to generate audit for this object. In fact the protection is encapsulated by Security Descriptor structure (SD). Namely, the SD has only four essential fields and two of them are ACLs. The first one (DACL) controls access while the second (SACL) is used to generate audit. There is a lot of objects that can be protected by Security Descriptor. It is files, folders, registry keys, printers, network shares, services, processes, threads, COM objects and many other Windows NT objects. The ACL consists of the header and a set of Access Control Entries (ACE). The number of ACEs is varying so the size of ACL differs from time to time. Each ACE of the DACL allows access to object or on the contrary denies access. When user tries to receive an access to securable object Windows NT compares the SID of user and the SID of its groups with SIDs stored in ACEs. If SID stored in ACE matches the user SID or group SID then NT tests the access mask stored in ACE to determine whether required access should be granted or not. The obvious conclusion is that the ACEs that allow access should be placed in the end of ACL while ACEs that deny access should be placed at the beginning of the ACL.

Let's suppose that we need to add new ACE to an existing ACL. As you see it could not be done by adding ACE to the end of ACL. It may occur that the ACE should be added to the beginning of ACL. Moreover in many cases adding of new ACE requires the other ACEs of ACL to be changed. In other words the ACL manipulation is not easy. In addition MS documentation says that ACL should be considered as opaque data. It means that API functions only should be used to edit ACLs.

So far so good. There is a set of functions that really operate by ACLs and allow to add or delete ACEs. They require a lot of memory allocations/deallocations and pointer manipulations. Of course it is not convenient. From my point of view the most convenient way of ACL editing is using array of ExplicitAccess entries. There are two functions in API that allows such approach. I mean GetExplicitEntriesFromAcl and SetEntriesInAcl functions. The first one works fine but there are some strange features in the second function. May be I am doing something wrong but the ACL changes produced by this function are unpredictable. I've played with it a lot of time and sometimes it works fine while sometimes it does not work. It does not return error codes but does not change ACL as required. As a result I had to write my own :-) implementation of this function. To make ACL editing as simple as possible I've created the TsvACLCenter component. On the next step you will know how to use it.