summaryrefslogtreecommitdiff
path: root/capabilities.mdwn
blob: fc1b36e0d3716a1d9f0dc59970273dd065af678d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
A capability is a protected reference.  It is a reference in that
it designates an object; it is protected in that in cannot be
forged.  A capabilities both designates the object it refers to and
carries the authority to manipulate it.

By binding [[designation]] and [[authorization]] together, capabilities
simplify [[delegation]].  Imagine that program instance A wants to
tell program B to use a particular file to store some data.
Further imagine that A and B are running in different [[TrustDomains]]
(e.g., with different UIDs).  If A sends B just the name
of the file, B needs to first ensure that he does not accidentally
enable A to access the file on his own authority.  That is, B wants
to protect against A hijacking his authority.  (This problem is
refused to the [[ConfusedDeputy]] problem.)  Also, since A likely
sent a string to identify the file to B, the identifier lacks a
[[NamingContext]] and therefore may resolve to a different object
than A intended.  Be ensuring that designation and authorization are
always bound together, these problems are avoided.

Unix file descriptors can be viewed as capabilities.  Unix file
descriptors do not survive reboot, that is, they are not
[[persistent]].  To work around this, [[ACL]]s are used to
recover authority.