ROS2 Security: CLI tools

[gbiggs]

@aalon

Overall this is a good approach, but it relies on environment variables which could be error-prone and introduces the minor inconvenience of having to invoke the CLI tool in a different manner.

If the ros2cli tool supplies the environment variable itself when it runs, then that removes the error-prone aspect and the inconvenience for the user. The user wouldn’t even need to know it was happening.

@aalon

From the user’s perspective, usage would stay exactly the same. Since CLI nodes would start with the same prefix, say _ros2cli_node, you could simply setup security for all CLI nodes by using that prefix,

I got the impression from another post of @ruffsl’s that any kind of wildcard matching when doing security policies was a Bad Idea[tm].

@aalon

This obviously complicates the setup, but regardless - What’s the use case for that discrepancy between the CLI nodes? Is that a discrepancy we’d want to keep? in ROS1, CLI nodes are all visible as far as I know. Considering that this functionality is at the CLI layer and can be easily ignored with --all, I wonder whether that discrepancy is something worth keeping.

This sounds to me more like an oversight in the ros2cli tools implementation than an intentional design choice.