You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to a DDS related size constraint it may be advantageous to provide users an option to reduce the size of generated access control permission files via a lossy transform leveraging posix rule expressions. In particular, such an option could be used to * wildcard over permissions within a node's own private namespace, and/or over action related topics used by clients and servers as well.
As first encountered in ros-swg/turtlebot3_demo#34 (comment) , default enclaves with moderate numbers of node profiles can easily result in signed permission files exceeding 64KB, causing the DDS security handshake to fail as discussed in a SROS2 matrix channel thread, due to the size limits for RTPS packet properties, as clarified in the recent security working group meeting:
Ideally, such limitations could be avoided by generating separate and smaller enclaves specific for each different participant, as opposed to using one monolithic enclave for containing all profile permissions. To use such multiple enclaves however will require further extension to roslaunch in order for users to easily orchestrate prescribed enclaves to different spawned ros2 processes.
In the interim, the DDS security spec allows for the used of posix expressions within permission rules, allowing users to substitute multiple closely related rules using a single wildcarded expression, abbreviating the permissions considerably. After discussing with @mikaelarguedas offline, we think this may best be achieved by extending the template transform to take a optional argument parameter to adjust how private related namespaces are expanded into DDS related topic rules.
Although using such wildcard approximations would be a lossy transform for minimal spanning permission profiles, enabling the option within the transform itself would afford users who necessitate such compromises to leave there own ros2 policy files source definitions unaltered. E.g:
Due to a DDS related size constraint it may be advantageous to provide users an option to reduce the size of generated access control permission files via a lossy transform leveraging posix rule expressions. In particular, such an option could be used to
*
wildcard over permissions within a node's own private namespace, and/or over action related topics used by clients and servers as well.As first encountered in ros-swg/turtlebot3_demo#34 (comment) , default enclaves with moderate numbers of node profiles can easily result in signed permission files exceeding 64KB, causing the DDS security handshake to fail as discussed in a SROS2 matrix channel thread, due to the size limits for RTPS packet properties, as clarified in the recent security working group meeting:
Ideally, such limitations could be avoided by generating separate and smaller enclaves specific for each different participant, as opposed to using one monolithic enclave for containing all profile permissions. To use such multiple enclaves however will require further extension to roslaunch in order for users to easily orchestrate prescribed enclaves to different spawned ros2 processes.
In the interim, the DDS security spec allows for the used of posix expressions within permission rules, allowing users to substitute multiple closely related rules using a single wildcarded expression, abbreviating the permissions considerably. After discussing with @mikaelarguedas offline, we think this may best be achieved by extending the template transform to take a optional argument parameter to adjust how private related namespaces are expanded into DDS related topic rules.
sros2/sros2/sros2/policy/templates/dds/permissions.xsl
Lines 256 to 264 in 54e80d5
Although using such wildcard approximations would be a lossy transform for minimal spanning permission profiles, enabling the option within the transform itself would afford users who necessitate such compromises to leave there own ros2 policy files source definitions unaltered. E.g:
The text was updated successfully, but these errors were encountered: