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.
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.
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.
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…
So now we need that other @reviewers gives a second +1. Then we could grant your snap usage of shared memory interface after publisher vetting. Once permissions are granted your snap should pass automatic review cleanly
