Hello,
infonet-kiosk was rejected at manual review on 14 July 2026 for the shutdown plug (review request 2757021) and I was pointed here. I am requesting installation permission for the four super-privileged interfaces the snap plugs. I am not requesting auto-connection for any of them: every connection is made explicitly, either by our own gadget in the image or by a one-shot provisioning script run once per device.
name: infonet-kiosk
description: Device agent and bundled Chromium for our own fleet of Ubuntu Core
digital-signage appliances. Runs a Node supervision agent plus Chromium
rendered on ubuntu-frame. Unlisted, published by Odytek, used only on
hardware we own, image and provision ourselves (custom gadget + model
assertion) in the schools we operate. Not intended for public use.
snapcraft: PRIVATE (the plugs section is reproduced verbatim below; happy to
share the full file with the reviewers on request)
upstream: PRIVATE
upstream-relation: publisher and sole maintainer — the snap, the agent and the
gadget are all our own in-house software
plugs:
shutdown:
request-type: installation
reasoning: logind reboot over D-Bus, for three appliance-lifecycle
functions — (1) remote reboot triggered by an operator from our
management dashboard, (2) a scheduled weekly maintenance reboot, and
(3) the agent's self-heal escalation, where a device wedged past a
threshold (no server contact, frozen compositor, renderer crash loop)
reboots itself as a last resort. On unattended screens in school
hallways this is the difference between a device that recovers on its
own and one that needs a technician on site. We only ever reboot; we do
not need snapd-control or any broader system control.
usb-mount:
interface: mount-control
attributes:
mount:
- what: /dev/sd*
where: $SNAP_COMMON/usb-import
type: [vfat]
options: [ro, nodev, nosuid, noexec]
request-type: installation
reasoning: devices are provisioned by inserting a signed USB key holding
config.json and our organisation CA certificate. The snap's wrapper
mounts the key itself, imports the data and unmounts. The mount is
read-only, nodev/nosuid/noexec, vfat only, and lands at a fixed path
inside $SNAP_COMMON. Only signed *data* is ever read from the key,
never code. We first tried udisks2 — on Ubuntu Core there is no
automount, and the mounts it created were not visible in the snap's
mount namespace, so the import never saw the files.
block-devices:
request-type: installation
reasoning: required to make the mount-control plug above actually work.
The snap's device cgroup only admits nodes belonging to connected
interfaces, so mount(2) on /dev/sda1 fails EPERM with no AppArmor and
no seccomp denial at all, even though the mount-control rule is present
in the generated profile. block-devices is what puts the node in the
cgroup. We do not read or write block devices directly; the only access
is the read-only mount described above.
cec0:
interface: custom-device
attributes:
custom-device: cec-dev
request-type: installation
reasoning: HDMI-CEC on our Raspberry Pi models. The slot is declared by
our own gadget and exposes only /dev/cec[0-9]. The agent uses it to
power the attached TV panel on and off on schedule so screens are not
left burning overnight. Access is confined to the CEC character device;
no other device node is exposed.
For reference, the matching slot in our gadget:
slots:
cec-dev:
interface: custom-device
custom-device: cec-dev
devices:
- /dev/cec[0-9]
The snap is unlisted and strictly confined. Connections are made explicitly at image build or provisioning time, never automatically. In each case we asked for the narrowest capability that does the job: reboot rather than full system control, a read-only noexec vfat mount at a fixed path rather than general filesystem access, and a single CEC character device rather than raw device access.
Happy to answer any questions,
Thank you, Cedric (Odytek)