On 4/7/21, Matt Rice
It is a bit difficult to introduce string -> capability lookups without introducing some form of ambient authority, where the object connectivity graph of a typical capability system is heavily reliant on application and services having direct connectivity. service managers of the sort introduce a difficult many to many applications -> service manager, service manager -> services type of object graph, which in turn loses many valuable properties...
That's one of the reasons why UX/RT won't be a pure capability system (compatibility with legacy Unix code without relegating it to a "penalty box" is another major one). Any general-purpose OS needs to have some facility for giving objects names that are meaningful to humans. UX/RT will use a per-process ACL-like mechanism for files to which access can be authorized statically. For files to which access is granted by another process, either a file descriptor transfer or a "path capability" mechanism will be used. To use the path capability mechanism, the granting process will write the path of a file into the grant list of the receiving process, creating a new path capability file in the process directory (these will be named with integer IDs in a separate space from FDs). The receiving process will then open this file, with the open being directed to the granted path according to both the namespace and permissions of the granting process rather than those of the receiving process. This will allow re-opening and deletion of granted files unlike with file descriptor transfers, but will still mitigate the risk of confused deputy vulnerabilities.