Privileged Interfaces required for iris-incubator

I am following up on reviewer feedback after a Snap Store rejection.

snap store listing:
snap name: iris-incuvers
snap publisher: Incuvers Inc

We are developing a Raspberry Pi snap that will monitor various sensors to control an incubator environment. This will include sending telemetry to an MQTT broker as well as displaying it on an attached screen. The snap set to is private as it will only work for our specific hardware setup (sensors, screen, input, etc)—I can’t imaging someone wanting to install this snap other than when using our setup.

The snap needs privileged access to some interfaces that are not automatically connected (gpio-control, network-manager, shutdown, framebuffer, i2c, spi, serial-port, etc).

At the moment, I’d like to publish to the snap store (edge) to test out over the air updates before shipping beta units. This is still in development and I am not yet certain of all the privileged interfaces that will be needed.

1 Like

Hey @dav!

A handy tool for troubleshooting/understanding denials and getting interfaces recommendations is snappy-debug. If you haven’t used it yet, do so and feel free to ask any questions here so we can help!

If you only need to monitor sensors, can the network-manager-observe interface be used instead? network-manager is a privileged interface which allows to configure networking and this is not your use case iiuc.

Following the same reasoning, can you please explain why you need gpio-control? It allows privileged access to hardware so probably gpio is enough?

In general, could you please explain the reason for each interface you would like auto-connection? In case you are interested or have further questions, you can read more about our Process for aliases, auto-connections and tracks

@dav ping, can you please provide the requested information?

Sorry for the late reply.

For network-manager:
The device has a very limited interface (just a rotary knob—no keyboard), so we opted to host an access-point and have the user setup their networking through a webserver (via the access-point). Once the user inputs their requirements (SSID/password/ethernet), we apply the changes and reboot.

For gpio-control:
We use the gpio inputs to connect the rotary knob as our sole human interface device.
The gpio’s are also used to trigger different lighting for the microscope, some which use the spi interface. I am not sure if the spi interface falls under the gpio-control (using wiring-pi) so I added both.

For serial-port:
Although we use an arduino to interface directly with the sensors, we use the serial-port to interface between the pi and arduino. Again, I am not sure if serial-port can simply be absorbed into the gpio-control umbrella. I want to mention we do open the /dev/ttyUSB0 and /dev/ttyAMA0 devices (to flash the arduino’s firmware and communicate with the it, respectively).

For shutdown:
In case the user wants to unplug the device, we have a selectable shutdown option (we also offer a reboot in order to enter a service-menu).

For framebuffer:
Our main app runs using pygame that directly interfaces with the framebuffer (SDL2) (we don’t want X11 to try to stay lightweight).

Note: I doubt this is not the full list of auto-connections needed. We are still trying to look at what apparmour plugs for us in devmode in order to explicitly add them in the snap. I may add the new ones here as we discover them.