Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nodes should consider FQN path when searching for own secure root #68

Closed
ruffsl opened this issue Sep 12, 2018 · 6 comments
Closed

Nodes should consider FQN path when searching for own secure root #68

ruffsl opened this issue Sep 12, 2018 · 6 comments
Labels
enhancement New feature or request

Comments

@ruffsl
Copy link
Member

ruffsl commented Sep 12, 2018

Nodes should expand node_secure_root using local_namespace so that unique secure configuration files in the secure root directory may be passed to namespaced nodes. Given namespacing often necessitates special modification to security credentials, a node with a alternate namespace may not inherently be capable of reusing security credentials with another node of the same name.

E.g.
Nodes /talker and /foo/talker may require require separate security permission given one may published to /chatter and the other to /foo/chatter; not to mention the additional sub system topics and services that may be affected by the namespace prefixing.

Tentative workaround:
ruffsl/rcl#1

If this sounds reasonable, I could clean up and PR my patches above.

@codebot
Copy link
Member

codebot commented Sep 12, 2018

Hmm, very good point. Do you think it would be useful to first search for the FQN, and if it's not there, search for the non-qualified node name? (I'm not sure if that's a typical or valid use case)

@ruffsl
Copy link
Member Author

ruffsl commented Sep 12, 2018

Do you think it would be useful to first search for the FQN, and if it's not there, search for the non-qualified node name? (I'm not sure if that's a typical or valid use case)

I'm not sure I'd like that sense of indeterminism when specifying where to retrieve security artifacts. Plus, one may want to wholly reserve the top root folders for nodes that are indeed actually top level namespace. E.g. /_ros2cli_node

@codebot
Copy link
Member

codebot commented Sep 12, 2018

That makes sense. Thanks for explaining. Using only the FQN seems reasonable, then. @mikaelarguedas and others may want to chime in, but I think this all sounds good.

@mikaelarguedas
Copy link
Member

Thanks @ruffsl for reporting.

Indeed I think the approach described in ruffsl/rcl#1 is good. Feel free to open a PR for it.

+1 for using only the FQDN: I see it as a security risk and / or surprise for users if a node with an FQDN not matching the structure of their keystore is allowed to join the secure network and talk. I think it's fair to expect that people enforcing security have rules matching exactly the final name and namespace of their nodes

@ruffsl
Copy link
Member Author

ruffsl commented Sep 19, 2018

Indeed I think the approach described in ruffsl/rcl#1 is good. Feel free to open a PR for it.

Ok please see ros2/rcl#300 and ros2/rcutils#119

@ruffsl
Copy link
Member Author

ruffsl commented Nov 21, 2018

Resolved with ros2/rcl#300 and ros2/rcutils#119 merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants