Classic confinement request for rviz2

store-requests classic-confinement
1

  • name: rviz2

  • description: RViz2 is the 3D visualization tool for the Robot Operating System 2 (ROS 2). A developer runs it on their workstation to visualize live robot state — subscribing to topics (sensor data, TF frames, point clouds, markers, custom messages) published by ROS 2 nodes running on the host — and to load RViz display plugins installed on the host system.

  • snapcraft: The snap definition lives at rviz2_snap/snap/snapcraft.yaml.

  • upstream: GitHub - ros2/rviz: ROS 3D Robot Visualizer · GitHub (BSD-3-Clause)

  • upstream-relation: This snap is packaged and maintained by Canonical Robotics.

  • supported-category: tools that dlopen/plugin arbitrary user-provided code, and that must interoperate with host-installed toolchains

  • reasoning:

    • Loading host plugins (dlopen of arbitrary host code): RViz2 discovers and dlopens display plugins at runtime via the ROS 2 ament plugin index and pluginlib. In the robotics ecosystem these plugins are provided by other ROS 2 packages installed on the host under /opt/ros/jazzy (and in the user’s own colcon workspaces). Under strict confinement these host paths are not visible and the plugin .so files cannot be dlopen’d, so any RViz display beyond the small built-in set fails to load. This is functionally equivalent to the supported category for snaps that must run arbitrary user-provided code that lives outside the snap.
    • Custom message types defined outside the snap: RViz2 must introspect and deserialize messages whose type support libraries (_rosidl_typesupport.so and message packages) are defined by the user’s own packages on the host, not bundled in the snap. Visualizing a custom MarkerArray-like or sensor message requires loading those host-provided typesupport libraries at runtime — again a dlopen of code outside the snap that strict confinement cannot satisfy.
    • Graphics stack must match the host kernel: RViz2 uses OGRE/OpenGL for rendering. As documented in the snapcraft.yaml, we deliberately do not ship the Mesa/GL/DRI userspace so that the GPU userspace resolves against the host driver matching the host’s kernel DRM. Classic confinement runs in the host namespace, allowing the correct host graphics libraries to load.
    • I evaluated strict confinement with the ROS 2 content interface and the relevant plugs. It works for the self-contained built-in displays, but there is no interface that lets RViz2 discover and dlopen the open-ended set of plugin and custom-message libraries installed on the host. I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces (ROS content sharing, opengl, x11/wayland, home) and strict confinement cannot support loading host-installed RViz plugins and host-defined custom message type support, which is core to the tool’s purpose.
2

This request has been added to the queue for review by the @reviewers team.

3

Hello @RoboticsCommunity :slight_smile:

The reasoning for classic confinement is well-understood, and since the publisher is already vetted, publisher vetting is not required.

I am happy to grant classic confinement to your snap as soon as a version is available in the store!

4

Thanks! I have just pushed the snap to the store.

5

Hello @RoboticsCommunity :robot:

Granting classic to the rviz2 snap, this is now live!

1 Like