If I am using electron app, should I then set false for allow-sandbox?
FYI, In docs there is sth like this:
For some web applications, such those using Electron,
it is often useful to disable the internal sandbox and rely
on strict confinement, forcing the snap to use `allow-sandbox: false`.
To do this, specify `--no-sandbox` on the command line for your application.
I don’t have an answer right now, but I’ve been reviewing and updating the “kiosk” tutorials to ensure they reflect current best practice. I’ll take a look at the issue you raise after the holidays, it may be that there’s a better way to get the access needed by the snap.
In the meantime, @ogra’s suggestion amounts to replacing:
Thank you. I switched to browser-support and now I get less errrors:
Please check the errors and some hints below:
- (NEEDS REVIEW) 'daemon' should not be used with 'browser-support'
- human review required due to 'deny-connection' constraint (on-classic) declaration-snap-v2_slots_connection (terminal-kiosk, x11)
As mentioned above, I’ve been reviewing this and other tutorials. The changes I’ve proposed have not landed on the website yet. But you ought to be able to apply them manually from the PR (look at the “Files changed”):
The browser-support interface provides privileged system access to snaps, and is meant for user-launched snap applications (i.e. non-root) like an actual browser. Thus, there is a manual review required for your snap since daemons run as root, but kiosk applications are a special case where you have a daemon running as root, but it is necessary to use browser-support. This issue should probably be resolved as soon as the reviewers get to your snap in the queue.
an alternative to what ian said is to drop privileges and to run your whole snap as the snap_daemon user instead of running as root … but depending on the app that might require a lot of patching or a wrapper or whatnot …
I don’t think the review-tools are smart enough to figure that out, since there’s no way to tell from the snap.yaml if a given daemon drops privilege, at least without additional support in the snap.yaml for specifying which user a daemon should run as.
I expect this to be the position with the updated tutorial. From my testing:
$ review-tools.snap-review *.snap
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored.
Warnings
--------
- security-snap-v2:daemon_with_browser-support:daemon
(NEEDS REVIEW) 'daemon' should not be used with 'browser-support'
electron-hello-world-kiosk_0.1_amd64.snap: FAIL
(Compared to the previous version of the tutorial I have removed the need to review X11 etc., and for manually connecting the browser-support interface on classic.)
NB browser-support is not a requirement for all kiosk apps, just those using electron or similar.
@alan_g Hi, I applied your changes, and just like in your testing I get the same error on automatic review
(NEEDS REVIEW) 'daemon' should not be used with 'browser-support' security-snap-v2_daemon_with_browser-support (daemon)
So now, I assume the only thing for me is to wait for a manual review. Is it always going to be like this ? is it going to be like this with every update I push to Ubuntu store for this app? Is it possible to get an exception for it somehow to be able to pass it automatically ?
And one more thing, after applying your suggestions, now I get this warning:
2020-01-07T09:04:12Z terminal-app.daemon[8583]: ##################################################################################
2020-01-07T09:04:12Z terminal-app.daemon[8583]: If you are experiencing problems with your GUI app (e.g. bad fonts), please run:
2020-01-07T09:04:12Z terminal-app.daemon[8583]: snap connect terminal-app:x11-plug terminal-app:x11
2020-01-07T09:04:12Z terminal-app.daemon[8583]: ##################################################################################
I do not experience any issues with my app. I know that, before your applying your changes, I ran this snap connect, but maybe this warning is not needed anymore ?
There is currently no way to avoid a manual review for browser-support nor a way to run electron without browser-support. But my experience as a publisher is that this is a one-time deal and that updates do not require reviews for the same interfaces. (Any delay now is likely due to a backlog after the holidays.)
I am working on improving the experience of developing “kiosk” apps, and needing a manual review when using electron is one of the “speed bumps” I hope to resolve in the mid-long term.
That suggestion (it isn’t a warning) comes from a shared project that may still be used by snaps which need the X11 interface to be connected. I agree it is confusing with the updated tutorial, but I can’t simply delete it.
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.
