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
|
[[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]].
"""]]
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.
|
