Thank you for this explanation. 
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:
- 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)
- 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:
- 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
- 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
@PiotrD - unless I just missed it, I don’t see the name of the snap you are interested in. What snap is this? What are your plans for this snap wrt distribution? Is a brand store something that you have considered for your project/business? If you have more questions about brand stores, please see https://docs.ubuntu.com/core/en/build-store/. Once you’ve decided, please respond back here if you’ll pursue that route or the public store.
Hi,
I didn’t mention app name before, it is waiting for an approval here:
Application is planned to be run only on a specific company devices. If I make any updates, I just want to push it to every device tracking stable channel. So the only way right now is it set it up as private snap.
Regarding brand store, I read about it and it could be the best option, but I found somewhere on forums that pricing for it is “crazy” ~ sth like 10k USD a year or more. Maybe, it was an old post. But for a brand store for just one small app that is going to be tracked by no more than 100 devices (right now less than 10) that pricing is way to big. If I am mistaken about a price, please let me know.
Brand stores are often used with a fleet of devices with an associated brand (eg, an appliance manufacturer with various models) with a lot of features that may not be required for your use case (again, https://docs.ubuntu.com/core/en/build-store/ has details with contact information to discuss site specific requirements).
Are you saying that you are planning on not distributing the snap in the public store and keeping it a private snap?
I’m not convince this is worth doing at present. It adds another packaging difference between “desktop” and “kiosk” snaps and these differences are a pain point. (See Make Desktop Qt 5 application run with mir-kiosk on Ubuntu Core for an example of the confusion it causes.)
There will always be differences between desktop environments and embedded ones, but ideally the process for packaging an app should be deployment agnostic.
At a high level the logic seems suspect:
- for kiosk we use daemons so the app autostarts
- using daemons means we run (or start) as root
- because we run as root some interfaces need manual review
- to avoid this we require a declarative way to drop privileges and avoid that review
Maybe a better answer is for there to be some way at installation to indicate that the snap should autostart?
Autostart as what user? The only thing we have today is system-usernames with the publisher promising to have the snap drop privileges, so the manual review provides a gate. In the future we will support specifying the user/group for systemd to use in the unit in the snap.yaml, but we still need to declare system-usernames for the available names that can be specified with user/group. When that is done, it will correctly start as non-root without the publisher having to do anything else (and it would pass automated review). I mentioned you because I figured in that future world, we still need to declare system-usernames so the effort of doing that now is not wasted, but perhaps there is also something temporary about how to have the snap drop privileges to help ease with speed bumps.
Perhaps you are talking about autostarting things in a user session? That would also be fine and perhaps more appropriate, but is farther out (core doesn’t have user sessions yet, for example). My suggestion is to ease developer friction immediately. If you prefer to wait until the future work (whether that is the user/group or the farther out user session/autostart), that is of course your call.
Yes, it is going to be distributed as private snap. Not in a public store.
I noticed that you rejected latest revision of my app. From the comment, I understand that I should just add
system-usernames:
snap_daemon: shared
section to snapcraft.yaml and nothing more, because Electron drops privileges itself I think, at least I read it somewhere here that it does. And if you approve it, there won’t be any manual review required anymore. Am I correct?
@jdstrand sorry for the digression (I know that there are gaps that need filling before we can reach anyone’s version of the ideal world).
With the current state of system-usernames (needing to inject code to drop privileges) I don’t believe it would simplify the process of packaging software for “kiosk” deployment.
Hmm I tried adding:
system-usernames:
snap_daemon: shared
section like mentioned here: https://snapcraft.io/docs/snap-format
but I get following error while building:
Issues while validating snapcraft.yaml: Additional properties are not allowed ('system-usernames' was unexpected)
script returned exit code 2
My snapcraft file looks like this:
name: terminal-app
version: '0.1.7'
summary: Terminal electron app for a Kiosk
description: |
Terminal app for a Kiosk
base: core18
confinement: strict
grade: devel
system-usernames:
snap_daemon: shared
apps:
terminal-kiosk:
command: desktop-launch xwayland-kiosk-launch "$SNAP/terminal-linux-x64/terminal" "--no-sandbox"
daemon:
daemon: simple
restart-condition: always
command: desktop-launch xwayland-kiosk-launch "$SNAP/terminal-linux-x64/terminal" "--no-sandbox"
environment:
XWAYLAND_FULLSCREEN_WINDOW_HINT: window_role="browser-window"
plugs:
browser-support:
network:
....
Any ideas?
I think you either need to use a more recent snapcraft (i.e. on edge I think) or you need to use passthrough.
Thanks, I added it, but unfortunately I cannot build a working kiosk snap with a latest snapcraft.
https://forum.snapcraft.io/t/after-update-to-snapcraft-3-9-5-electron-kiosk-build-fails/15088
Maybe you might know a solution for this.
@jdstrand
Finally, after struggling to build my app with latest snapcraft, I was able to release snap with
system-usernames:
snap_daemon: shared
but now it gets automatically rejected, because of previous manual rejection.
Could you look into it ?
should I just create another topic regarding this snap approval ?
EDIT.
OK, there was a button “Request manual review” … 
Hmm It has been 9 days since I requested Manual review. Is it always that long ?
@PiotrD - sorry this slipped off our list since it wasn’t in the ‘store-requests’ category.
Thank you for adjusting your snap to use ‘snap_daemon’. @advocacy, in comment 14 I mentioned:
can you review this snap’s suitability for the public store and vet the publisher?
@PiotrD - in addition to the vetting, assuming this snap will be granted access, can you state that you intend to not change your snap to run a command which plugs ‘browser-support’ under the root user (ie, you will keep using the ‘snap_daemon’ with any commands/daemons that plugs “browser-support”)?
Hi, @jdstrand
What do you mean by “vet the publisher” ? verify ? by creating a store-request in forum ?
I have already read this:
"the publisher should be vetted, as with classic snaps "
and I still don’t get this, because my terminal application runs in strict confinement and it is not intended to be a public snap. Only private, for internal use. Isn’t it possible to just publish snap as private only? Please explain it for me.
And Yes, I will not change this snap to run a command which plugs “browser-support” under root user.
@PiotrD - you don’t need to do anything, the @advocacy team will reach out to you (those instructions were for them, not you).
Ok, great. So I will just wait for information, that it was approved. How long does it usually take ?
Vetting has been done, +1 from advocacy team.