From 6e7cac446ae4a3330270cfc675d49ff5295543a1 Mon Sep 17 00:00:00 2001 From: GNU Hurd wiki engine Date: Mon, 20 Aug 2007 08:49:57 +0000 Subject: web commit by NealWalfield: Create. --- capabilities.mdwn | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 capabilities.mdwn diff --git a/capabilities.mdwn b/capabilities.mdwn new file mode 100644 index 00000000..fc1b36e0 --- /dev/null +++ b/capabilities.mdwn @@ -0,0 +1,23 @@ +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. \ No newline at end of file -- cgit v1.2.3