I’m happy with being more verbose and distinguishing ros communication with capabilities, I will revise the ipc subsystem to have different names for capabilities.
DDS topic mangling
Is there a discussion regarding the translation of yaml -> dds xml DomainParticipant permissions document is concerned?
I’ve observed that each rmw implementation mangles topic names based on the subsystem (topic, actions, services) using constants replicated through each repo. Is there a thread which discusses consolidation of topic prefixes/suffixes into a library to ensure each implementation uses the same constants? This way we can programmatically ensure the generated permissions xml document is accurate to each rmw implementation.
Notes on ruffsl capability primitives
We will need to distinguish the differences between parameters and the rest of the “subsystems.” With the above structure, read/write refers to the remote node requesting an operation on the parameter node (outputs) whereas all other subsystems have an input/output capability defined. That convention means we will need to “whitelist” all nodes to be able to reply (output) to parameter read/write requests. The new yaml definition would look as follows:
SROS2 yaml policy changes
Definitions
| name | description |
|---|---|
| access_permission | The access permission of that node for the specified icp |
| ipc | Inter-process communication, how messages get from one node to another |
| ipc identifier | The specific subsystem id to provide access to (topic name, service name…) |
| ipc types | The inter-process communication subsystem (topics, services…) |
Options
Most ipc permissions are given on a client/source basis.
Parameter permissions are slightly different. These specify whether this node is allowed to read/write to another node.
| ipc_type | identifier | access permission options |
|---|---|---|
| topics | topic name | subscribe, publish |
| services | service name | request, reply |
| actions | action name | call, execute |
| parameters | node_name | read, write |
Policy yaml file layout
nodes:
<node_name>:
<ipc_type>:
<ipc_identifier>
access:
-<access_permissions>