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
|
[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="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.
|
