On 4/7/21, William ML Leslie <[email protected]> wrote:
> 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.
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
