name: superpaper
base: core18
version: '1.2.0'
license: MIT
icon: snap/gui/superpaper.png
summary: Multi-monitor wallpaper manager with spanning, multi image and more.
description: |
Superpaper is an advanced multi-monitor wallpaper manager
for GNU/Linux supporting various desktop environments.
On top of standard spanning and multi image wallpaper features
it supports spanning corrections for monitor bezels, and if your
displays don't have the same pixel density it will take that into
account as well.
Other features include: slideshow, saving wallpaper setting profiles,
hotkeys, manual wallpaper offsets, alignment testing tool and
Windows support.
grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
plugs:
kde-plasma-dbus:
bus: session
interface: dbus
name: org.kde.PlasmaShell
freedesktop-dbus:
bus: session
interface: dbus
name: org.freedesktop.DBus
apps:
superpaper:
command: bin/superpaper
plugs:
- desktop
- desktop-legacy
- unity7
- x11
- gsettings
- kde-plasma-dbus
- freedesktop-dbus
- dbus
- home
- removable-media
parts:
superpaper:
plugin: python
python-version: python3
source: .
build-packages:
- python3-wxgtk4.0
- python3-wxgtk-media4.0
- python3-wxgtk-webview4.0
- python3-dbus
- libxcb-render0-dev
- libgdk-pixbuf2.0-dev
stage-packages:
- python3-wxgtk4.0
- python3-wxgtk-media4.0
- python3-wxgtk-webview4.0
- python3-dbus
- libxcb-render0-dev
- libglu1-mesa
- libgpm2
- libslang2
- libgdk-pixbuf2.0-dev
requirements: [requirements_full_linux.txt]
The dbus interface is intended for you to create a dbus service so that other applications (or the shell) may interact with your application via dbus. It is not used for granting permissions for your application to communicate with other dbus services.
This message:
" dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.186" (uid=1000 pid=23518 comm="/snap/superpaper/x7/usr/bin/python3 /snap/superpap" label=“snap.superpaper.superpaper (enforce)”) interface=“org.kde.PlasmaShell” member=“evaluateScript” error name="(unset)" requested_reply=“0” destination=":1.21" (uid=1000 pid=2059 comm="/usr/bin/plasmashell " label=“unconfined”)
"
Since my response in 2017, we’ve refined our thinking around interfaces like this and classic. The requested access would have your snap send a script over dbus for PlasmaShell to execute. Since plasma shell runs the script in the context of plasma (ie unconfined), this would allow breaking out of application confinement (similar requests came up recently for gnome extensions and nautilus extensions). To prevent sandbox escape, plasma would have to be rearchitected to support running scripts under a different security context. The requirements for classic are understood, but per recent discussions with @pedronis for the analogous gnome extension request, this snap’s use of evaluateScript means it is unfortunately not a candidate classic.
If there was another wallpaper API you could use instead of org.kde.PlasmaShell.evaluateScript, then we could consider adding an interface to snapd for that API so your snap could work with strict confinement.
Thank you for the detailed response. I feared as much that strict confinement would not work.
As far as I know and can find, there is no other API to set wallpapers on KDE Plasma. I take that this means that a snap like this cannot be confined. Do I understand correctly that this use case is not considered viable for a classic confinement release?
If this snap is not considerable as a classic, can it be released in the store under some other confinement like devmode, or is this snap wholly unsuited for the snap store?
Edit:
I’d like to add that from my limited perspective my use case would seem to differ from the gnome and nautilus extensions. This snap is a standard application that has to interact with native APIs of the system to do what it does; it is not built as a system specific extension. Given that the platforms/plasmashell are not likely to be rearchitectured anytime soon, I’d see this as a reason for classic confinement.
The API your snap is using allows for sandbox escape by asking the shell to execute script outside of the security context of the snap with no means of limiting what the script can do. Therefore, yes, the snap cannot be used with strict confinement and, unfortunately, precisely because there is no path forward with regard to rearchitecting plasmashell, it is not a candidate for classic. It is possible for you to use devmode, but devmode snaps by design do not auto-refresh, so this is not a recommended distribution method for your snap. Until the situation changes and wallpaper-specific APIs become available or there is some progress for mediating org.kde.PlasmaShell.evaluateScript, I recommend using traditional packaging methods to distribute your software.
@pedronis - if my assessment is in error, please overrule
[…] outside of the security context of the snap with no means of limiting what the script can do.
In my case the script to be run by evaluateScript is predefined within the Python code of the snap. I admit that my knowledge on security issues is next to non-existent but to me this would seem that the script that is run can at least be vetted? This of course does not help with confinement but to me it would seem that it allows one to see that arbitrary code is not run?
@jdstrand Are your conclusions made here final if nothing is heard from @pedronis ? Is my above point on the nature of the script unhelpful/irrelevant?
@hhannine - they are final insofar as this falls under the unsupported use cases for classic. In these cases, for full transparency I ping an architect (eg, @pedronis) in case new information has come to light that changes current thought processes and overrule as appropriate.
