I noticed your root running process trying to access pulseaudio files in /run/user/1000/… which would also be disallowed which certainly might cause your snap to misbehave.
I was only running as root so that I could run strace. The application wouldn’t normally be run as root and it doesn’t die on .Xauthority when not run as root.
Thanks for clarifying that.
In short, @mborzecki’s initial suggestion to add /dev/nvidia* rwm, does make WebGL work in an Electron snap. If this change didn’t cause security problems and were to be accepted, I could go ahead and publish Polarr to the snap store.
==Work==
I tried this
and the only denial I got was
Time: Dec 20 14:52:28
Log: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=7676 label="snap.webgl.webgl" peer_pid=1142 peer_label="unconfined"
DBus access
= AppArmor =
Time: Dec 20 14:52:28
Log: apparmor="DENIED" operation="file_mmap" profile="snap.webgl.webgl" name="/dev/nvidiactl" pid=7807 comm="webgl" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
File: /dev/nvidiactl (mmap)
Suggestion:
* verify program isn't using an executable stack: https://forum.snapcraft.io/t/snap-and-executable-stacks/1812
which made me think that I did this wrong:
Adding /dev/nvidiactl m, near the end of the file didn’t help, but then I tried
and that gave me WebGL in both the test “webgl” snap and the “polarr” snap in snap versions both 2.30 and 2.28 whereas they didn’t have WebGL before. I thought that you meant that adding /dev/nvidiactl m, was a better or more correct way of changing /dev/nvidia* rw, to /dev/nvidia* rwm, but I was mistaken and might have saved a lot of time by trying mborzecki’s suggestion first.
You can use sudo strace -u <your username> ... (this is described in the other forum post.
Was this needed after clearing the executable stack? When you cleared it, I thought you said you had no denials…
Also, can you provide an electron snap somewhere that points at chrome://gpu?
Here is an electron snap that points to chrome://gpu/.
When I cleared execstack on the binary that electron-builder produced before snapping it, I didn’t get any denials but webgl didn’t work when the snap was installed and run with strict confinement. Can clearing the execstack on a binary make it not function as it did before?
Thanks! I don’t see a snapcraft file. How do I create a snap package out of that?
Yes under certain circumstances, though there are few legitimate reasons to need it and since chromium as a snap doesn’t need it, I suspect it is something else. You can read about executable stacks here: Snap and executable stacks and here: https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
npm install && npm run snap
Will give you a .snap file in the dist directory. It’s electron-builder.
Ok, I had to install node6 for the above to work.
I found that node_modules/electron/dist/electron has an executable stack. This module seems to come from https://github.com/electron/electron and this issue would lie with them. I suggest someone file a bug with them, pointing them to https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks and Snap and executable stacks. It is really important to understand this is not a ‘snap’ issue-- this is a problem in their builds that opens their code up to certain kinds of attacks that would otherwise be protected against if their build didn’t have an executable stack. It is also important to mention that the chromium builds in the Ubuntu archive (and therefore the chromium snap) does not end up with an executable stack, so this doesn’t seem to be a chromium content api issue. I believe @Wimpress has been working with them, perhaps he can file the bug?
Now that we know where the executable stack is coming in, I’ll take a look at webgl.
As it happens, I obtained access to a computer that had an nvidia card, so installed 17.10 on a USB stick, booted from it on that system and tested there. Before doing that, I tried the webgl snap on an intel system and found that there were no denials but that webgl was ‘unavailable’. I thought this might be a missing stage packages since you mentioned that it worked in devmode, but not without. I also remembered that the chromium snap had fixes for webgl, so I looked at that and found that the webgl snap did not stage libgl1-mesa-glx, but chromium did. Once I added that to stagePackages, intel worked everywhere. I then installed those snaps on the nvidia machine and reproduced the denial with strict mode/execstack, but found it worked with strict mode/no execstack:
16.04*/intel 17.10/intel 17.10/nv
devmode/execstack yes** yes** yes**
devmode/noexectack yes** yes** yes**
strict/execstack yes** yes** no***
strict/noexectack yes** yes** yes**
* 16.04 was done in a vm
** no denials (had to add to stagePackages: libgl1-mesa-glx first though)
*** /dev/nvidiactl 'm' denial
Looking at your initial report I see that you are not staging this package in polarr. Can you try your polarr snap by rebuilding after adjusting packages.json to have:
...
"snap": {
...
"stagePackages": [
"default",
"libgl1-mesa-glx"
],
...
Fantastic, I’ll try that.
Hopefully it was clear, stage that package and clear execstack 
Thanks, that worked. I was able to publish the app to the Snap Store.
1 Like
Yay @Wimpress, I wonder if it would make sense to include libgl1-mesa-glx by default in electron-builder’s stagePackages?
Quite possibly. I’ve noticed the recent builds of electron are requesting GL now. I’ll look see what can be done to improve the defaults in electron-builder and electron forge.