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

Running discovery process as root breaks existing processes running as normal user when SHM is used #3475

Open
1 task done
ksuszka opened this issue Apr 19, 2023 · 2 comments
Labels
bug Issue to report a bug

Comments

@ksuszka
Copy link

ksuszka commented Apr 19, 2023

Is there an already existing issue for this?

  • I have searched the existing issues

Expected behavior

Running an arbitrary ROS command as a root should not break existing ROS ecosystem running under a non-root user.

Current behavior

Running an arbitrary ROS command under SHM transport as a root breaks service discovery for ROS nodes running as a non-root user.

Steps to reproduce

Open four terminals. In the first terminal, start publishing messages as a non-root user:

docker run -it --net=host --privileged --ipc=host -u 5678 -e HOME=/tmp ros:humble ros2 topic pub /foo std_msgs/msg/String "data: foo"

In the second terminal, start a process to retrieve messages as as the same non-root user

docker run -it --net=host --privileged --ipc=host -u 5678 -e HOME=/tmp ros:humble ros2 topic hz /foo

You should see proper output, as expected.

In the third terminal, run some ROS command as a root:

docker run -it --net=host --privileged --ipc=host -u 0 ros:humble ros2 topic hz /foo

You should see WARNING: topic [/foo] does not appear to be published yet - it is not preferable, but can be explained by other issues like #2624 (comment)

In the fourth terminal, run the same command as in the second step:

docker run -it --net=host --privileged --ipc=host -u 5678 -e HOME=/tmp ros:humble ros2 topic hz /foo

This time, you will see WARNING: topic [/foo] does not appear to be published yet.
The previous command broke discovery of existing nodes.

Fast DDS version/commit

ros-humble-fastrtps-cmake-module/now 2.2.0-2jammy.20230112.142430 amd64 [installed,local]
ros-humble-fastrtps/now 2.6.4-1jammy.20230117.223829 amd64 [installed,local]
ros-humble-rmw-fastrtps-cpp/now 6.2.2-1jammy.20230117.225910 amd64 [installed,local]
ros-humble-rmw-fastrtps-shared-cpp/now 6.2.2-1jammy.20230117.225455 amd64 [installed,local]
ros-humble-rosidl-typesupport-fastrtps-c/now 2.2.0-2jammy.20230112.145514 amd64 [installed,local]
ros-humble-rosidl-typesupport-fastrtps-cpp/now 2.2.0-2jammy.20230112.145146 amd64 [installed,local]

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

This is yet another issue related to the shared memory transport in FastDDS (other related issues I found: ros2/ros2cli#598, #1750, #2624). However this experiment shows that the issue occurs not only when new connections between different users are established but can affect the service discovery for a single user.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

@ksuszka ksuszka added the triage Issue pending classification label Apr 19, 2023
@jsan-rt jsan-rt added in progress Issue or PR which is being reviewed and removed triage Issue pending classification labels May 7, 2023
@JesusPoderoso
Copy link
Contributor

Hi @ksuszka, thanks for the report.
We were able to replicate the issue, and recently we updated the documentation warning about the possible issues when launching any of the processes with a higher permission.
This issue is now categorized as bug, and we will look for solving this.

@JesusPoderoso JesusPoderoso added bug Issue to report a bug and removed in progress Issue or PR which is being reviewed labels Jul 10, 2023
@maxpolzin
Copy link

maxpolzin commented Aug 16, 2023

I have also encountered this issue.

For me it works to:

  1. start the container with these options: --network=host --ipc=host --pid=host
  2. run nodes inside the container with the same user id as nodes on the host

For convenience, I have created this repository with my setup to build (as root user) and run (with host's user id) ROS 2 packages/ nodes inside containers. This allows to use Shared Memory Transport (SHM) between ROS 2 nodes run inside the container and on the host.

https://github.com/rosblox/ros-template

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue to report a bug
Projects
None yet
Development

No branches or pull requests

4 participants