Description
i would like to open the discussion here 1st before moving in the implementation detail.
the ros2cli daemon is spawned implicitly the first time a user runs almost any ros2 introspection command (ros2 topic list, ros2 node list, ros2 service list, tab-completion, etc.). this implicit lifecycle is genuinely useful and it caches the discovery graph and gives the CLI low-latency answers. but the implicit-by-default behavior produces some classes of recurring user pain.
- inherits the first invoking shell's environment (ROS_DOMAIN_ID, RMW_IMPLEMENTATION, ROS_SECURITY_*, FASTRTPS_DEFAULT_PROFILES_FILE, etc.)
- continues serving subsequent ros2 invocations from possibly different shells/users with possibly different environments
- exposes no authentication on its XML-RPC methods (loopback-bound, but not user-scoped)
Motivation
the daemon snapshots the spawning shell's environment and then answers all subsequent CLI calls, a sequence like this silently produces wrong results. same failure mode happens with RMW_IMPLEMENTATION, ROS_LOCALHOST_ONLY, custom DDS profile XML, security enclave paths, and colcon-sourced workspace overlays.
security-enabled deployments are explicitly told to avoid the daemon. see https://docs.ros.org/en/rolling/Tutorials/Advanced/Security/Introducing-ros2-security.html
and there's no project-wide way to honor this guidance.
Avoid using ros2 daemon because it may not have security enclaves, and enough time duration should be given for the discovery in ROS 2 secured network.
XML-RPC surface has no authn/authz. daemon's XML-RPC server binds to loopback only, which limits the threat model to local processes, looks fair. but within that model there is no caller authentication: any local process (including other users on a shared machine, sidecar containers sharing the host's loopback, or a compromised unrelated service) can call system.listMethods and the discovery introspection methods, learning the full ROS graph topology, node names, and topic names. for users running ROS 2 in multi-tenant CI runners, classroom shared hosts, or container images with side processes, the implicit daemon means this surface is exposed without the user ever knowing it was started.
Design / Implementation Considerations
probably ros2 daemon should be spawned when it is explicitly started by user command. so that user can know what configuration can be applied to the ros2 daemon process.
--no-daemon flag already exists, and that can be default behavior. and we can always use ros2 daemon start to start/stop the ros2 daemon process explicitly.
Additional Information
related issues:
could be more related to ros2daemon.
Description
i would like to open the discussion here 1st before moving in the implementation detail.
the ros2cli daemon is spawned implicitly the first time a user runs almost any ros2 introspection command (ros2 topic list, ros2 node list, ros2 service list, tab-completion, etc.). this implicit lifecycle is genuinely useful and it caches the discovery graph and gives the CLI low-latency answers. but the implicit-by-default behavior produces some classes of recurring user pain.
Motivation
the daemon snapshots the spawning shell's environment and then answers all subsequent CLI calls, a sequence like this silently produces wrong results. same failure mode happens with RMW_IMPLEMENTATION, ROS_LOCALHOST_ONLY, custom DDS profile XML, security enclave paths, and colcon-sourced workspace overlays.
security-enabled deployments are explicitly told to avoid the daemon. see https://docs.ros.org/en/rolling/Tutorials/Advanced/Security/Introducing-ros2-security.html
and there's no project-wide way to honor this guidance.
XML-RPC surface has no authn/authz. daemon's XML-RPC server binds to loopback only, which limits the threat model to local processes, looks fair. but within that model there is no caller authentication: any local process (including other users on a shared machine, sidecar containers sharing the host's loopback, or a compromised unrelated service) can call system.listMethods and the discovery introspection methods, learning the full ROS graph topology, node names, and topic names. for users running ROS 2 in multi-tenant CI runners, classroom shared hosts, or container images with side processes, the implicit daemon means this surface is exposed without the user ever knowing it was started.
Design / Implementation Considerations
probably ros2 daemon should be spawned when it is explicitly started by user command. so that user can know what configuration can be applied to the ros2 daemon process.
--no-daemonflag already exists, and that can be default behavior. and we can always useros2 daemon startto start/stop the ros2 daemon process explicitly.Additional Information
related issues:
ros2clicommands for debug purpose sros2#293ROS_SECURITY_ENCLAVE_OVERRIDEdoes not effectively work as introduced sros2#306could be more related to ros2daemon.