summaryrefslogtreecommitdiff
path: root/capability.mdwn
blob: bb849caec25a1fc713620c2a12fc93b32a99c5f3 (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
[[meta copyright="Copyright © 2007 Free Software Foundation, Inc."]]
[[meta license="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]]."]]

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 [[trust_domains]]
(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 [[confused_deputy]] problem.)  Also, since A likely
sent a string to identify the file to B, the identifier lacks a
[[naming_context]] 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|persistency]].  To work around this, [[ACL]]s are used to
recover authority.