Hello all. I’m moving a conversation we had in the deprecated snapcraft@lists.snapcraft.io in order to continue with it. Thanks to Michael Hall, @rmescandon, Jamie Strandboge and @niemeyer for the support so far 
Original post:
Hello everybody.
I develop a graphical java-based application which is published in the Ubuntu Store as a snap package (sctrict confinment) called wallpaperdownloader to download, manage and set desktop wallpapers.
I'm developing version 2.7 which will bring KDE support, but for this I need to execute a shell script from Java. In classic confinement and natively, this script is executed without problems. I use this code to do it:
process = Runtime.getRuntime().exec("/bin/sh " + WDUtilities.getAppPath() + WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + wallpaperPath);
As you can see, I use /bin/sh command to run the script. This is the content of the script:
#!/bin/bash
# Changing wallpaper
qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript "var allDesktops = desktops();print (allDesktops);for (i=0;i<allDesktops.length;i++) {d =
allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup = Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image',
'file://"$1"')}"
This command changes the current wallpaper for version 5.8 or higher in Plasma.
When this part is executed within the snap package (strict confinement), nothing happens. I have tried to include bash and dash pacakges as stage-packages but it doesn work. Is this something that can be achieved using the snap package system?
Thank you very much!
Best,
Eloy
Michael Hall
Running a script inside of your snap with either /bin/sh or /bin/bash
should be no problem at all. However looking at your script I see that
you're making dbus calls out to the Plasma Shell, and that *will* be
blocked by the strict confinement.
You will probably need to get a snapd interface created to support this
dbus interface, or maybe you can use the generic 'dbus' interface and
specify this service, which would have to be manuall connected. I'm
hoping someone from the snapd or security teams can chime in and be more
specific about what your options are here.
Roberto Mier Escandón
Hey Eloy,
Maybe you have already tried this, but just in case, you can debug the
snap in confined mode [1], to see if there are some apparmor or seccomp
denials. That would give you some clues about what is causing snap not
to work and suggested solution.
sudo snap install snappy-debug
sudo snappy-debug.security scanlog <yoursnap>
Take a look also at /var/log/syslog
Cheers.
Jamie Strandboge
On Sun, 2017-04-16 at 21:06 -0400, Michael Hall wrote:
> Running a script inside of your snap with either /bin/sh or /bin/bash
> should be no problem at all. However looking at your script I see that
> you're making dbus calls out to the Plasma Shell, and that *will* be
> blocked by the strict confinement.
>
> You will probably need to get a snapd interface created to support this
> dbus interface, or maybe you can use the generic 'dbus' interface and
> specify this service, which would have to be manuall connected. I'm
> hoping someone from the snapd or security teams can chime in and be more
> specific about what your options are here.
>
It looks like your script is using qdbus to tell the PlasmaShell to run a script
for changing the wallpaper to something your snap specifies. Assuming your snap
ships qdbus, then the 'only' thing that would be required would be to add a
snappy interface to allow access to this dbus call.
A few things things:
1. today we have the 'unity7' interface for use on classic distributions. We'll
be introducing gnome and plasma interfaces for running snaps under those DEs
2. it looks like your qdbus command is sending a script over 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. If
this snappy interface was added, it would be considered a privileged
interface
3. is there another wallpaper API or standard KDE command line utility that can
be used instead of plasmashell that doesn't allow breaking out of
confinement? If so, I recommend using that instead-- then perhaps we can add
a 'desktop-wallpaper' interface.
For now, feel free to use 'confinement: devmode' in your snap and please file a
bug (with the 'snapd-interface' tag) here to request your interface addition:
https://bugs.launchpad.net/snapd/+filebug
Eloy García Almadén
Hi Roberto!
Finally I had some time to spend checking my application with snappy-debug tool. There is no error displayed when I try to run the script from wallpaperdownlader. However, there is another feature that is not working properly from the beginning and now I have some clue thanks to this debugger.
I have a button for opening a file manager via the application (java based application), and this button never worked. When I click on it, I obtain the next message in the debugger:le
= AppArmor =
Time: Apr 23 21:47:33
Log: apparmor="DENIED" operation="open" profile="snap.wallpaperdownloader.wallpaperdownloader" name="/usr/share/applications/" pid=18526 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /usr/share/applications/ (read)
Suggestion:
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
This is my snapcraft file:
name: wallpaperdownloader
version: "2.7"
summary: Download, manage and change your favorite wallpapers from the Internet
description: WallpaperDownloader is a simple GUI Java based application for downloading, managing and changing wallpapers from the Internet
grade: stable
confinement: strict
apps:
wallpaperdownloader:
command: wallpaperdownloader.sh
plugs: [x11, unity7, network-bind, home, gsettings]
parts:
# Pulls the code from the original source (master branch)
# desktop-gtk3 is a snapcraft part (snapcraft-desktop-helpers) from the Wiki: https://wiki.ubuntu.com/snapcraft/parts
# It enables desktop integration and gsettings manipulation from the confined application
# It is necessary to use gsettings interface (see above) in order to have a fully functional
# desktop-gtk3 part
# Github repository for snapcraft-desktop-helpers: https://github.com/ubuntu/snapcraft-desktop-helpers
wallpaperdownloader:
plugin: maven
source: ..
stage-packages:
# mate-desktop-common is necessary to have MATE gsettings schemas available for the application
- mate-desktop-common
after: [desktop-gtk3]
# It will copy wallpaperdownloader script into /bin/
# This script contains all the commands needed (sets env variables, launches the jar file...) to
# execute the application
exec:
plugin: dump
source: scripts
And this is my wrapper script:
#!/bin/sh
# Only for packaging!
# Script for snap packaging wallpaperdownloader application. It is not related to the code itself
# Old exports are not needed anymore because of desktop/gtk3 part use within snapcraft.xml configuration file
export HOME=$SNAP_USER_DATA
# Memory usage is limited to 256 MBytes of RAM
desktop-launch java -Xmx256m -Xms128m -jar -Duser.home=$SNAP_USER_DATA $SNAP/jar/wallpaperdownloader.jar
Do you have any suggestions?
Thank you very much in advance!!
Best,
Eloy
Roberto Mier Escandón
Hey Eloy,
Seems that wallpaperdownloader is trying to read files from
/usr/share/applications/ at some point, and that path is outside of snap
scope. If possible you should modify it to access a path in allowed
folders (SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or
$SNAP_USER_COMMON) instead.
Cheers.
Jamie Strandboge
On Sun, 2017-04-23 at 22:03 +0200, Eloy García (PC Actual) wrote:
> Hi again Jamie. Finally I has some time to spend with the snap package. My
> answers below:
>
> 2017-04-17 16:13 GMT+02:00 Jamie Strandboge <jamie@canonical.com>:
> > A few things things:
> >
> > 1. today we have the 'unity7' interface for use on classic distributions.
> > We'll
> > be introducing gnome and plasma interfaces for running snaps under
> > those DEs
> >
>
> Maybe using those new interfaces my snap could work out of the box?
Zygmunt (in To) was thinking about different ways to handle a wallpapers. I'm
not sure if he has created a forum post, but I think some of the things he was
thinking of would help here.
>
> > 2. it looks like your qdbus command is sending a script over 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.
> > If
> > this snappy interface was added, it would be considered a privileged
> > interface
> > 3. is there another wallpaper API or standard KDE command line utility
> > that can
> > be used instead of plasmashell that doesn't allow breaking out of
> > confinement? If so, I recommend using that instead-- then perhaps we
> > can add
> > a 'desktop-wallpaper' interface.
> >
> >
>
> I'm afraid this is the only way I found to change the wallpaper via command
> line. For Unity, GNOME or MATE things are a lot easier. They use gsettings,
> so there is no problem for this via gsettings interface.
>
Yikes, sending arbitrary scripts through plasma DBus API is not great from a
security perspective as it provides easy confinement escape. I bet that the
things that Zygmunt is thinking about will help you. If not, worse case a helper
DBus service could be written that only allows changing plasma wallpapers that
your snap would use and this service would do the plasma DBus API calls to
change the wallpaper on your behalf.
Lastly, note that the snapcraft@lists.snapcraft.io list has now been deprecated
and https://forum.snapcraft.io should be used instead. I suggest this discussion
be moved to the wallpapers forum topic (when it is created).
Gustavo Niemeyer
Hi Eloy, Roberto, Jamie,
Please note that the list is now integrated into the forum. You may of course continue to email each other about this subject, but to reach a wider audience a new topic needs to be open in the forum, or a new message sent to the mailing list address as it will have the same effect.
Thanks, and sorry for the trouble.