Here is how you build something close to an ACL mechanism on top of a capability system:
First, invent two objects: a group manager and a "user" object. Assume that you can compare two user objects for equality. Assume that a group manager accepts a user object capability and says "yes" or "no" according to whether that user object is a member of the group.
Note that services must be trusted not to abuse the user object. They already have the authority to act on your behalf; this is not an extension of new authority to the server objects.
The proposed mechanism differs from traditional ACL systems only in that the user object is first class. It is therefore possible for me to pass you my user object so you can use it.
This can be corrected as follows: interpose a trusted intermediary through whom all of my service requests go. The intermediary is per-process, and carries the user object associated with that process. This prevents the user object from being left open to manipulation by the process.
Why capabilities cannot be built on ACLs:
Basically, the problem is that user identity authorizes multiple objects. This violates the requirement that a capability must name a single unique object. While you could create a new group for every process, and a new user identity for every object, and then introduce some mechanism to pass the user identities from one process to another, the result would be highly inefficient -- you then need to do a set intersection on every object access.
Further, the authority and the object identifier become separated, in
that the process doesn't explicitly specify the user identity
(capability) under which it is performing each operation.
Broadly, this approach is not feasible in practice.
If we restrict ourselves to *existing* ACL systems, the test question is:
How do I grant to a single process being run by you (and not to you in general) the authority to access a specific set of my objects.
In most ACL systems, it is a base assumption that modification to the group and user tables is an administrator-only operation.
UNIX in practice uses an ACL system to control access to the persistent store (the file system), but internally uses capabilities. A file descriptor is a capability. The fatal flaws in this model are that file descriptors cannot be transferred between processes (there are some non-popular features in some systems that permit this, but none were designed with capability ideas in mind) and that not everything is protected by file descriptors. Processes, for example, have an intrinsic right to perform some fairly powerful system calls.
shap