Capabilities List and Access Control Lists

ACL’s and CL’s

Implementing an ACM as a 2D Array requires a significant amount of memory, and much of it will go unused
- The size of an ACM is the product of all subjects and objects in the system
- An ACM is often sparse, as most subjects will have no access over most objects
Consequently, ACMs are often condensed in order to save space.
In practice, an ACM is implemented using either a capabilities list, or an access control list.
- A capabilities list (CL) is a row-wise implementation that lists access on a per-subject basis. Each subject has a list of objects it can access and the permissions it has over those objects.
- An access control list (ACL) is a column-wise implementation that lists access on a per-object basis. Each object has as list of subjects that can access it and the permissions those subjects have over it.

Although CLs and ACLs are both more space-efficient than using a full matrix, they each come with their own properties to consider.

In a CL, access is handled via tickets. When a subject wants to access a resource, it presents a ticket as proof of permission. This has the following advantages:
- Simple and efficient implementation
- Easy to revoke access on a per-subject basis
However, this creates the following disadvantages:
- Concept of ownership (per object) is diffused rather than centralized.
- It is difficult to revoke access on a per-object basis.

In an ACL, access is handled via access control entries (ACEs). When a subject wants to access a resource, that resource traverses the list for the appropriate ACE. This has the following advantages:
- Strong, centralized ownership on a per-object basis.
- Easy to revoke access on a per-object basis.
However, this creates the following disadvantages:
- Implementation is less efficient.
- It is difficult to revoke access on a subject basis.