Move security related filesystem and env utilities outside rcl

[BorjaOuterelo]

Feature request

Feature description

Move file system dependant functionality to rcutils will increase the ROS 2 possible targets.

rcl/rcl/src/rcl/node.c

Line 320 in 3a5c3a3

node_secure_root = rcl_get_secure_root(name, local_namespace_, allocator);

In this concrete case, I propose to move rcl_get_secure_root API to rcutils.
This way, rcl will be "easy" to cross-compile for systems with no filesystem.
Keeping the core mostly platform-independent.

In rcutils there are already other utilities for the filesystem.

Implementation considerations

We propose to have and rcutils_get_secure_root API and be called in the same place as rcl_get_secure_root is called right now. These two pull request implements the proposed solution over dashing:

• Feature/add security directory rcutils#195
• Feature/remove security directory #544

[jacobperron]

It's probably better to consolidate discussion. To reiterate my comment (#544 (comment)):

I believe there was a past discussion about relocating/refactoring the security directory implementation, but I'm unable to find it at the moment. In any case, I don't think that moving the functionality to rcutils is the right thing to do simply because rcutils is a place for ROS-agnostic helpers for the ROS code base. Instead, perhaps creating a new package to contain the core security functions makes sense (e.g. rcl_security). I'd have to think about it some more.

[jacobperron]

I found the past discussion I was thinking about in #332. In particular, I agree with this #332 (comment):

I think the best solution (long term solution) would be to remove all of the use of filesystem and environment variable usage related to security from rcl itself, instead passing in the functions to do this from the client libraries or by using plugins (similar to how Connext's security works). The reason for this would be to make rcl more flexible, so that on systems which use a different way of configuring security or storing keys can customize their solution with a plugin or in the user code rather than having to modify rcl itself. Also for users who are not using security but are on machines which do not have things like filesystems.

[BorjaOuterelo]

I do agree with the #332 comment, isolate rcl from security configuration giving the users the right to implement theirs.

keep rcl "about the client library"

and

Also for users who are not using security but are on machines which do not have things like filesystems.

are appealing to us.

Is there any roadmap for such changes?

[jacobperron]

I'm not aware of any explicit roadmap, but we can start by using this ticket for tracking progress.

[jacobperron]

I've closed the connected rcutils PR and re-titled this issue. Rather than moving security utilities to rcutils, I think we should move the implementation to a separate package that clients can choose to opt out of. E.g. rcl_security

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2020-10-15/16849/1

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-without-a-file-system/16942/1

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-without-a-file-system/16942/4