Request: allow auto-connection for rosbot-xl

Hi All!

In the latest release (0.10.0+git3.g9e5897c) of the rosbot-xl snap we added a shared memory configuration for efficient ROS 2 communication.

Because of using:

plugs:
  shm-plug:
    interface: system-files
    write:
      - /dev/shm

I can see the Fail message: “human review required due to ‘allow-installation’ constraint (bool) declaration-snap-v2_plugs_installation (shm-plug, system-files)”. Please let us use this interface and if possible allow auto-connection.

Additionally I would be grateful for auto-connection functionality for the following plugs used in our snap:

  • serial-port
  • raw-usb

They are used for uploading a micro-ROS based firmware for STM32 microcontroller over the serial USB connection.

About rosbot-xl snap

rosbot-xl snap contains a ROS 2 driver for ROSbot XL mobile robot platform.


Thanks!

Dominik from Husarion

1 Like

Have you taken a look at

Using system-files for a device node is probably not the best thing to do…

1 Like

Hi @ogra ,

Thanks for your reply. Yes, I have tried, and it didn’t worked with shared-memory interface.

I tried with:

apps:
  rosbot-xl:
    command: usr/bin/launcher.sh
    daemon: simple
    install-mode: disable
    plugs: 
      - network
      - network-bind
      - shared-memory
    extensions:
      - ros2-humble-ros-base

Probably authors of this popular ROS 2 project had the same issue, and therefore used system-files instead of shared-memory interface: https://github.com/micro-ROS/micro-ROS-Agent/blob/iron/snap/snapcraft.yaml#L149 .

I need to have shared memory communication not only between different ROS 2 powered snaps, but also between snap and ROS 2 nodes running directly on the host.

1 Like

I dont think this is the correct syntax for the shared-memory plug, there are some examples at the bottom of the doc I linked above.

1 Like

Have an example from moi:

plugs:
  private-shmem:
    interface: shared-memory
    private: true

apps:
  joplin-desktop:
    command: opt/joplin-desktop/joplin --no-sandbox
    extensions: [gnome]
    plugs:
      - private-shmem

This shouldn’t need any store review.

Do note that’s giving your snap access to all of /dev/shm/ by bind-mounting it so that it can’t see other snaps or the host (and other snaps can’t see it). This is probably what you need but there are other ways to use shared memory; they likely require code changes in addition to interfaces, whereas if you you’re only using shared memory for IPC in a single snap, private alone makes it trivial without any application code changes.

For a bit of context. The application uses shared-memory to communicate with other programs through the ROS 2 framework. Other programs may of may not be snapped (bare, docker etc). Thus the need to access plain /dev/shm non-privately.

Having a look at the shared-memory interface, it seems that this could be achieved with a slot along the lines of:

slots:
  shmem-slot:
    interface: shared-memory
    write: ['*'] # paths are relative to /dev/shm
    private: false 

Any thoughts? Would that essentially be the same as the initial system-files-based attempt ? Would it make it through reviews ?

The reason i was commenting here at all is that system-files is not designed for files in /dev.

Device node handling in the confinement involves a lot more than just file access (udev tagging, ACLs, shuffling things around in the namespace etc) which is why we do have usually dedicated interfaces for anything in /dev …

If the shared-memory interface is not sufficient, it might need to be extended or we might need a completely new interface. I’m not sure abusing system-files here for something it was not designed for is the best solution (but no reviewers have commented here yet, after all it is their decision in the end)

From:

Consumers of this interface require a snap
 declaration for distribution via the Snap Store 
and acceptance in the store requires that the 
interface is not be used to access:


 - system files where the snap is not the clear
   owner (eg, /dev, /proc, /sys, /usr, etc).

 - paths in /dev, such as /dev/sda1 Access to 
  /dev device nodes requires both AppArmor 
  policy and device control group inclusion, but 
  the system-files interface does not have 
  enough information to generate the necessary 
  policy to enable these use cases. As such, 
  purpose-specific interfaces should be used 
  instead, such as block-devices or raw-volume.

I understand your point @ogra. It simply seems indeed that, at the moment, there is no dedicated interface addressing the use case at hand. Maybe the use of system-files here could be allowed while a proper interface comes up.

1 Like

@ogra , thanks, you are right. It is possible to use shared-memory interface:

I replaced:

plugs:
  shm-plug:
    interface: system-files
    write:
      - /dev/shm

apps:
  rosbot-xl:
    command: usr/bin/launcher.sh
    daemon: simple
    install-mode: disable
    plugs: 
      - network
      - network-bind
      - shm-plug
    extensions:
      - ros2-humble-ros-base

with

slots:
  shm-slot:
    interface: shared-memory
    write: ['*'] # paths are relative to /dev/shm
    private: false
plugs:
  shm-plug:
    interface: shared-memory
    shared-memory: shmem-slot
    private: false

apps:
  rosbot-xl:
    command: usr/bin/launcher.sh
    daemon: simple
    install-mode: disable
    plugs: 
      - network
      - network-bind
      - shm-plug
    slots:
      - shm-slot
    extensions:
      - ros2-humble-ros-base

and now the shared memory communication works great!

All I need to do is to connect a plug to a slot:

sudo snap connect rosbot-xl:shm-plug rosbot-xl:shm-slot

So my final request is to allow auto connection for ROSbot XL snap for the following interfaces:

# for rosbot-xl app
sudo snap connect rosbot-xl:shm-plug rosbot-xl:shm-slot
# for rosbot-xl.flash app:
sudo snap connect rosbot-xl:serial-port snapd:ft230xbasicuart
sudo snap connect rosbot-xl:raw-usb

The latest build for snapcraft.io still have 2 fails related to the shared-memory interface:

Do you accept my changes?

Best,

Dominik

3 Likes

As i said above, I’m not a reviewer but your changes will definitely have a good chance to get approved (while system-files would have been rather controversial) you’ll have to wait til the @review-team gets around to process the request now…

2 Likes