On 4/7/21, William ML Leslie
On Wed, 7 Apr 2021 at 22:13, William ML Leslie
Oh, I should probably clarify with an example: when porting setuid binaries, the common practice (at least to a first order) is to have the "normal" filesystem be the default root filesystem of the exec server, but to also gain a capability to the caller's filesystem to use for resolving user-provided filenames. It's not ideal, and yet already a huge step forward over the unix permissions model.
That's a little bit like the path-capability mechanism I'm planning to implement, although the path-capability API will only provide paths for informational purposes such as displaying in a GUI. Also, UX/RT won't have any client-visible concept of a "capability to a filesystem" (that's way too coarse-grained for my liking; security boundaries usually don't correspond to disk partitions or network shares, and having to set up some kind of filter filesystem for every directory/file you want to control access to is cumbersome). However it will be possible to give a process access to all files in a directory (mount point or otherwise) through either its permission list or through a path capability.