> Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward.

Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all. This is similar to how generational arenas work in some game engines, IMO.

AFAIK Android performs something similar to this with the storage URLs that are provided to apps, which will be different depending on which picker provided the file/media, etc. Apple probably also does something similar, but I'd imagine with objects rather than strings.

▲

bheadmaster a day ago | parent | next [-]

> Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all.

Which complicates the initial premise that

> capabilities are the simplest model in the world. You hand out objects. You can call methods on the object. What that method call has access to depends on the permissions on the object, not your permissions.

Which is exactly what the parent said. Capabilities sound simple at first, but require complex machinery to work.

▲

naasking 19 hours ago | parent | prev [-]

> Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all

This is basically using access control lists to mimic a capability system [1]. The capability folks did something similar in "Polaris", their layer atop Windows XP that enforced principle of least authority by default. If only MS had taken that and run with it.

[1] A Distributed Capability Computing System (DCCS), http://www.webstart.com/jed/papers/DCCS/

[2] Polaris: Virus-Safe Computing For Windows XP, https://cacm.acm.org/research/polaris-2/

▲

btilly 19 hours ago | parent [-]

How equivalent this is to ACLs depends on what "provenance" means here.

One of the strategies with capabilities is that I do not hand you the capability that I own to X. Instead, I create a proxy Y that can make requests of X, and then hand you the capability to make requests of Y.

If I later stop Y, you lose access.

This can be viewed as a kind of provenance. The history of how the access came to be is reflected in the actual capability. The downside, obviously, is that we've added overhead. But this strategy can allow us to do a number of interesting things. Like split an existing capability into multiple finer grained ones.

▲

naasking 18 hours ago | parent [-]

"Construct proxy" need not be a primitive in the core system though. If message passing is the only means of communication, then interposition to create facets or attenuate permissions naturally follows. This works with ACLs too. All you need to do is restrict the rights amplification authority to discriminate what a capability actually points to, but this is a rights amplification operation and so should itself be a capability that's closely held. DCCS did this right, IIRC.

	▲	btilly 17 hours ago \| parent [-]
		Yes. Just as we can build an ACL on a capability system, we can build a capability system on an ACL. But this approach is more natural in a capability system. You have to write software differently for dealing with "I got permission through an ACL" versus "I got information through a capability". So when the default expectation is, "I get a capability," the right abstraction is already there for "...and this capability has something more behind it."