summaryrefslogtreecommitdiff
path: root/capabilities.mdwn
blob: a483c0e7d5447d6f13ce0a04e03f5df3e496f77b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[[license text="""
Copyright © 2007 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.2 or any later version
published by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts.  A copy of the license is included
in the section entitled [[GNU_Free_Documentation_License|/fdl.txt]].

By contributing to this page, you agree to assign copyright for your
contribution to the Free Software Foundation.  The Free Software Foundation
promises to always use either a verbatim copying license or a free
documentation license when publishing your contribution.  We grant you back all
your rights under copyright, including the rights to copy, modify, and
redistribute your contributions.
"""]]

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.