Problem with releasing kiosk app

This is accurate and it is recognized that this is a pain point. @ijohnson is right to point out that the check is in place because the interface grants more access to the snap than is appropriate for passing automated review/auto-connection when the process is run as root (as daemons currently are). More concretely, the permissions allow affecting root running processes outside of the snap (including system and other snaps’ daemons).

Today, there are two options:

  1. if the snap is intended to be included in a brand store, then the publisher can distribute the snap in their brand store without worrying about the check (because the publisher owns the brand and access to the brand store is limited to devices associated with the brand)
  2. if the snap is intended to be distributed via the public store, then:
    • the snap should be reviewed for suitability for distribution in the public store (eg, whether or not, due to branding, intended use, device deployments, etc, the snap makes sense for the public store)
    • the publisher should be vetted, as with classic snaps
    • the publisher modifies the snap to use system-usernames where the daemon is modified to drop privileges and the publisher agrees to not revert to starting as root

Going forward, I think we can improve this on two fronts:

  1. make the use of system-usernames in the kiosk tutorial and documentation. @alan_g - please note that system-usernames discusses how to drop privileges in a snap-compliant fashion
  2. adjust snapd to support declarative snap.yaml to tell snapd to create systemd unit directives to start the daemon under the specified user/group. This work is planned but not yet roadmapped (I plan to try to do it as time allows, but someone should feel free to propose a PR. The only difficult part will be defining appropriate snap.yaml syntax, but that can be discussed as part of PR review)

When ‘2’ is implemented, then we can adjust the store check to not prompt for manual review if the snap.yaml specifies the user/group directive. ‘1’ is not needed if ‘2’ is implemented. UPDATE: ‘1’ is still needed with ‘2’, it just becomes simpler