In this particular example, the capability to see a directory & it's children is what's getting passed around & refined (starting with the top level directory the app has, then perhaps winnowing down the capability to pass to the upload middleware).
But capabilities can represent other things too. The program might get capabilities to open a socket, to listen on a socket, to send or receive data on a socket. Those capabilities might similarly be refined & passed around to libraries.
The broader model of capabilities is that you can only do whatever you are passed, only exercise whatever capabilities you get. You have no other way to talk to the platform, no platform api, other than the set of capabilities you get from your caller. So capabilities keep getting winnowed down, shrunk, to the right size, where we expect, for the file-upload middleware, that it can read some bytes off some sockets it gets passed, and where it can write files, into a certain directory, but having no other capabilities, it can not do any more than that.
While filesystem sandboxing was core to my example, it's just one demonstration of what a capability might be. The underlying model for how that sandboxing is implemented is "capability based". There's a pretty long history for capability based systems. Not a simple example, but the "E language" is a pretty well known example from 1997 that tried to push capabilities into an interesting distributed frontier: http://www.erights.org/
You can have sandboxes that are not capability-based. It refers to a specific style of modeling the problem. (EDIT: and e.g. the Rust crate referenced doesn't actually sandbox the process, but uses design and kernel APIs to make it harder to mistakenly access the wrong files - still a capability system)
It's not just filesystem sandboxing. One capability could be access to part of the filesystem, sure, but another might be networking, access to camera, microphone, USB devices, playing audio, Bluetooth, maybe you wanna give raw access to a block device rather than just access to a filesystem, ...
Capabilities are a more generic, core idea.
In this particular example, the capability to see a directory & it's children is what's getting passed around & refined (starting with the top level directory the app has, then perhaps winnowing down the capability to pass to the upload middleware).
But capabilities can represent other things too. The program might get capabilities to open a socket, to listen on a socket, to send or receive data on a socket. Those capabilities might similarly be refined & passed around to libraries.
The broader model of capabilities is that you can only do whatever you are passed, only exercise whatever capabilities you get. You have no other way to talk to the platform, no platform api, other than the set of capabilities you get from your caller. So capabilities keep getting winnowed down, shrunk, to the right size, where we expect, for the file-upload middleware, that it can read some bytes off some sockets it gets passed, and where it can write files, into a certain directory, but having no other capabilities, it can not do any more than that.
While filesystem sandboxing was core to my example, it's just one demonstration of what a capability might be. The underlying model for how that sandboxing is implemented is "capability based". There's a pretty long history for capability based systems. Not a simple example, but the "E language" is a pretty well known example from 1997 that tried to push capabilities into an interesting distributed frontier: http://www.erights.org/