-
Notifications
You must be signed in to change notification settings - Fork 46
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
Comments
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) |
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. |
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. |
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 |
Ok please see ros2/rcl#300 and ros2/rcutils#119 |
Resolved with ros2/rcl#300 and ros2/rcutils#119 merged. |
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.
The text was updated successfully, but these errors were encountered: