[staticassertion]

> It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to.

No, this is incorrect. Let's just quote wikipedia,

> A capability (known in some systems as a key) is a communicable, unforgeable token of authority.

communicable. It is practically the whole point that you can say "hey, here's a capability I have, now you have it".

Yes, it matters deeply if a capability is leaked. To name something is to authorize something, in capabality land.

No, you do not need to ask for it to be transferred. As with file descriptors in linux you can fork to delegate (or otherwise pass the handle around). Again, it is fundamental to capabilities that the capability is the authorization.

Dropbox's approach is faithful. And, in order to deal with these limitations of capability systems, Paper supports ACLs as well as capabilities. I think it's going to be a huge problem if Fuschia doesn't, but I don't know what they do - certainly some sort of MAC is desirable.

[Rusky]

I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle.

Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be bad. But that's more of a question of API design- even fork is, in this sense, asking for the capability to be transferred. This is a very different problem than the one Dropbox has- no amount of random guessing, or side channel information leaks, or anything else like that, is going to land a capability in another process's kernel table.

[staticassertion]

Yes, accidentally sharing a capability is a leak. If I accidentally printed out a capability it would be 'leaked' and anyone who reads that capability now has obtained it an dcan use it.

> you can in principle forge a URL in a way that you could never forge a file handle.

Maybe it would be better to not talk about fs apis, because they're not really capability based, so I suspect that's the confusion.

The point is that if someone has a capability, they have that capability. There is no additional access control or checking in a capability based system. You absolutely have to consider things like rotation and revocation.

[Rusky]

I'm specifically talking about Fuchsia and other kernel-based capabilities here. You fundamentally cannot print out that kind of capability in any way that matters- the only thing that determines whether a process has it is the table in the kernel, not whether it can produce a particular bit pattern.

In this sense, fs APIs are a fine example, as long as you keep the ls/.. caveats in mind. If you have a file descriptor for something inaccessible through the global file system namespace, then the only way to grant that to another process is via specifically-designed APIs like domain sockets or fork.

As I said in my first comment, there are of course other reasons you might want to revoke a capability. But unlike Dropbox URLs, true capabilities are unforgeable, so you don't need to rotate them out simply to make them harder to guess- they're already unguessable.

[staticassertion]

I think the short version is that you're just not talking about capabilities.

[Rusky]

How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?

[staticassertion]

So to recap, a capability is a value that represents authorization. The value must not be forgeable, the value must be communicable.

If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability.

Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, but you can "guess" a uuid in the same way that you can "break AES" with a bruteforce, which is to say, you can't.