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