the access matrix

Suppose you want to write down, completely and exactly, who is allowed to do what to everything in a system. The most direct way is a big table. Down the side you list the actors — the protection domains. Across the top you list the things they might act on — the objects (files, devices, even other domains). In each cell you write the operations that this actor is permitted on that object. That table is the access matrix: an abstract, total picture of all the rights in the system at once.

Each row is one protection domain; each column is one object; cell (row D, column O) holds the set of rights domain D has over object O — entries like read, write, execute, or owner. If a cell is empty, that domain has no access to that object at all. The matrix even models its own administration: special rights such as owner or copy can sit in cells, letting one domain grant or revoke another's access, and a domain can appear as a column too so that the right to switch into it can be recorded. So the matrix captures not only what everyone may do but also who may change those permissions.

The access matrix is mostly a thinking tool, not a real data structure, because for any sizable system it would be enormous and almost entirely empty — most domains have rights over only a handful of objects. So real systems never store the full matrix; they store it sparsely in one of two natural ways. Slice it by column and you store, with each object, the list of who may touch it — that is an access-control list. Slice it by row and you give each domain the list of objects it may touch, as unforgeable tokens — those are capabilities. Understanding the matrix is the key that makes both encodings click, because each is just a compressed view of the same conceptual table.