I’m creating a snap package of Tizonia (https://github.com/tizonia/tizonia-openmax-il) and I’m currently facing some problems when running the installed snap on Fedora 25. The issue in question is an “Access error” returned by the pulseaudio API when the app is trying to connect to PulseAudio
After discussing the issue with the developers over at the #snappy IRC Channel on freenode, the Access Denied issue apparently has to do with Pulseaudio’s authentication cookie not being accessible for some reason when Awesome WM was the desktop environment. Switched over to Gnome Shell, and the issue was gone.
So now, after getting Tizonia more or less working on Fedora 25 with Gnome Shell, I’ve noticed that the same snap will not work in Ubuntu 16.04 (Unity) unless the snap is installed in ‘–devmode’.
The same error, i.e. ‘Access denied’ while accessing pulseaudio.
I’m pinging this thread again because recently I decided to take another stab at snapping Tizonia, hoping that the apparmor denials issue that I saw the last time would be gone by now. But apparently it is not:
So my snap is now in the "candidate’ channel, and I still see the same run-time problems because the application is denied access to PulseAudio:
My observations so far:
‘sudo snap install --candidate tizonia’ works well on Fedora 27. Application installs correctly and no issues with PuseAudio access. Everything seems good on F27.
‘sudo snap install --candidate tizonia’ also works well on Manjaro 17.06. No issues with PulseAudio.
The same command on Ubuntu 16.04 won’t work, since the apparmor denials show that access to PulseAudio is denied. I can make things work if I add ‘–devmode’. These are the messages that I see in journalctl when running the app without --devmode
Finally, on openSUSE Tumbleweed, the application is unable to access PulseAudio even in --devmode. So this looks like a different issue from the one in Ubuntu 16.04.
To access the X11 system you need either or both of desktop (possibly desktop-legacy instead) and x11 plugs connected. Your app is attempting to access the X system via a socket in /tmp, so you do need this to prevent denials related to those socket files in /tmp.
Thanks!, adding the ‘x11’ plug to the yaml file fixed this problem.
I don’t understand though what the ‘x11’ plug has to do with PulseAudio access. Should somehow the ‘pulseaudio’ plug have an implicit dependency on the ‘x11’ plug?. I’m not a PulseAudio developer, just a user of the pulseaudio library.
From an app developer point of view, this is to me perhaps the most important issue with snaps right now. The fact that the ‘interfaces’ concept appears as an internal detail of the snap system that has been exposed a bit “too much” to the app’s developer. I.e. you need to be aware of the interfaces required by your code and by some of your dependencies’ code. Better tooling might be able to help here in the future (e.g. thinking of some form of static or dynamic analysis of interface issues).
Another question that came to mind while snapping Tizonia is what is the point of listing “auto-connected” interfaces in a ‘strict’ snapcraft.yaml file. If they are auto-connected, I believe they will be completely transparent to most users of the app, so you could make perhaps the case of them being “auto-granted” to all ‘strict’ apps anyway?. I’m probably missing something here.
Don’t get me wrong, I love the idea of packaging my app as a snap. By far the nicest vehicle I’ve found of distributing it so far. But interfaces has made it a bit harder than I feel it could have been, so just sharing a bit of feedback here.
So after adding ‘x11’, the PulseAudio access denial is gone when I install and run the snap locally, but pushing it to the store produces this message:
Will need manual review...
The Store automatic review failed.
A human will soon review your snap, but if you can't wait please write in the snapcraft forum asking for the manual review explicitly.
If you need to disable confinement, please consider using devmode, but note that devmode revision will only be allowed to be released in edge and beta channels.
Please check the errors and some hints below:
- desktop interfaces (x11) specified without a corresponding meta/gui/*.desktop file. If using snapcraft, please see https://snapcraft.io/docs/build-snaps/metadata#fixed-assets. Otherwise, please provide a desktop file in meta/gui/*.desktop (it should reference one of the 'apps' from your snapcraft/snap.yaml).
Note that I have not added 'desktop; and/or ‘desktop-legacy’ yet.
I think you’ll need to wait for @jdstrand to review your snap as it will need an exception to the store to allow it in without a .desktop file. Alternatively ship a desktop file.
I think the store exception would be the best solution for Tizonia. Being a command-line app there’s not much you can do by launching the app from an entry in the desktop menus. Plus I suspect that would provide me with a fresh new set of headaches
This could be related to Spotify does not play audio, where the PulseAudio client library couldn’t locate the socket under strict confinement.
The X11 access is a fallback path where it will try to read the PULSE_SERVER property on the root window to get the socket path. We merged a fix for this to snapcraft-desktop-helpers to work around this by setting the PULSE_SERVER environment variable here:
You’re not using snapcraft-desktop-helpers, but you could probably incorporate a similar fix in your tizonia-snap-wrapper.sh script.
I’ve tried it, removed ‘x11’ plug and added the PulseAudio fix to my wrapper script, and the denials came back. Here is the commit (hopefully I didn’t miss anything):
So I’m reverting to @lucyllewy 's solution of adding ‘x11’. That seems to to work well. As @popey mentioned, Tizonia’s snap will need the store exception, which I hope won’t be an issue?.
If it is just an issue of log messages but the app works fine, then perhaps it is better not to plug x11. That will result in better confinement and not trigger the manual review process.
Looking at the libpulse source code, it will only try to connect to the X server if the DISPLAY environment variable is set. So perhaps adding unset DISPLAY to your wrapper script might be enough to silence the warnings.
I’ve finally changed my mind and decided to add a minimal .desktop file. Tizonia has it’s own media framework that can also do video, it is just not exposed yet on the command-line application. So I believe keeping ‘x11’ is just fine.
Now with the .desktop file, all 3 launchpad builds are successful and the snap is being uploaded to the edge channel. So no need for manual review anymore.
apparently it is not: