this is XDG_RUNTIME_DIR … theoretically your app should have full write access to it, do you see any apparmor denials when this happens ?
@ogra is there anything I have to configure to allow scrot to work and save that image file? It doesn’t really say why it cannot save the image, it just says giblib error: Saving to file /run/user/1000/snap.swach/temp-screenshot.png failed.
I think this is the last major hurdle to getting our app working with Snapcraft, and while I am disappointed there seems to be no way to use electron-forge or electron-installer-snap without being a vetted publisher, I am pleased there is a workaround using electron-builder, even though it is very complicated and required a lot of trial and error.
If you could please help me resolve this one remaining issue, I would very much like to write a blog post to help others with this.
your app should normally have write access to XDG_RUNTIME_DIR (which is set to /run/user/1000/snap.swach/ in your case), I’m not sure why you are not …
open a second terminal, run journalctl -f | grep DENIED in it and start your app to see if there are apparmor denials …
@ogra this is what I get as output when I run that:
May 19 07:53:43 rwwagner90-VirtualBox audit[549]: USER_AVC pid=549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=3417 label="snap.swach.swach"
May 19 07:53:43 rwwagner90-VirtualBox kernel: audit: type=1107 audit(1589889223.551:78): pid=549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=3417 label="snap.swach.swach"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="org.freedesktop.DBus.Properties" member="GetAll" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="com.canonical.dbusmenu" member="AboutToShow" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="com.canonical.dbusmenu" member="GetLayout" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
well, that doesn’t show anything related to saving a screenshot …
if you did that action while capturing the log, I’m out of ideas …
i have never used the electron-installer-snap and my personal electron-builder attempts were unsuccessful too, which made me switch to a proper snapcraft.yaml using electron-packager (like you can see in the post above where i pointed to one of my apps on github). i’m not sure what the tool you are using does to prevent you from writing to XDG_RUNTIME_DIR …
@ogra If it were not an Electron app, what would we be looking for when this issue happens? I’ve switched to electron-builder on the advice in this thread, which did get the app running, but we need to be able to use the color picker, which uses scrot to take screenshots. Are there any interfaces we should be making sure to add or tweaks to permissions we can make somehow? These tools just create a snapcraft.yml behind the scenes, so it should work if we can ensure the correct settings are there.
Is it possible to please become a vetted developer? Since the .deb package works with no problems, I feel that if I were allowed to be a vetted developer, I could basically publish the same package. I do the signing and notarizing processes for MacOS and Windows with no issues, but there doesn’t seem to be a way to register a company as a trusted Snap developer, is there?
interfaces only help where you see denials in your log output … there was none for your secreenshot issue …
well, these generated snapcraft.yaml’s are as generic as possible so fine tuning or tweaks for specific features you add on top of the generic generation are hard to do (as you noticed). These tools are typically fine for general purpose (show a website and some basics) but electron has a gazillion of possible modules you can add with tons of different features that such a generator simply can not cover.
I’m not sure what you want to achieve by becoming a vetted publisher (and i’m not in any team to grant it anyway …)
Yes, but I can put anything you might recommend into the settings to be generated into the snapcraft.yml. The tool is not breaking the app, Snapcraft is making it impossible for scrot to save the screenshot for some reason, and we need a way to determine how to fix that. The problem would exist with or without electron-builder, as when I build for .deb everything works, but does not in Snap, so the issue lies with Snap.
My original build, the one that works as .deb from before the many days of trying workarounds used chrome sandbox, so I needed to be a vetted publisher to do that. It would be very much appreciated if I could become a vetted publisher. I have not found any docs on how to do so, but since it seems impossible to get Snap to allow the correct permissions, it’s worth a shot to become a vetted publisher and see if it works. If not, I may have to try classic confinement next.
I do not understand why .deb works flawlessly and Snap refuses to work, but there has to be a missing setting somewhere, and if we knew how to narrow it down, I could set that setting.
“allow-sandbox: true” is reserved for major browsers like Mozilla Firefox, Brave, Opera, Chrome, etc, not electron apps and as mentioned in this topic, there are many electron apps in the store that do not require it. I suggest creating a new topic in the “snapcraft” category since there will be a lot more people there to help you debug your snap than in the “store-requests” category.
Before you go and do that, since you don’t have any denials related to /run/user/1000/snap.swach/temp-screenshot.png in the logs, that suggests it might be traditional DAC permissions that is causing the problem. Can you:
- make sure that
/run/user/1000/snap.swachexists as an actual directory, not a symlink - if it does, is every directory element in the path owned by your user with (at least) 0700 permissions?
If the answer to all of the above is “yes”, then I suggest you run snap run --strace="-o ./trace" swach and see how it is failing. It is possible that giblib1 is actually having trouble somewhere else (eg, /snap/swach/x1/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot is not executable, something else, etc).
Armed with all of that information, if you still aren’t able to figure it out, asking in the ‘snapcraft’ category with this information can hopefully get you the help you need.
FYI, the bluez denials are just noise. The dbusmenu issues shouldn’t be what is causing your trouble but is being discussed in the turbosmtp topic.
This does appear to be a directory and the contents in it are owned by my user.
I tried this, but this is a ton of output in trace. What should I be looking for? I did a grep for giblib and got this:
12450 openat(AT_FDCWD, "/var/lib/snapd/lib/gl/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/var/lib/snapd/lib/gl32/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/var/lib/snapd/void/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/lib/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/usr/lib/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/lib/x86_64-linux-gnu/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/usr/lib/x86_64-linux-gnu/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = 10
12450 write(2, "giblib error: ", 14) = 14
12321 read(106, "giblib error: ", 65536) = 14
@jdstrand @ogra I tried running the command directly via command line and it works:
/snap/swach/19/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot /run/user/1000/snap.swach/temp-screenshot.png
So I suppose we have some kind of permissions issue when running inside of Snap?
It appears the permissions on scrot are for root:
-rwxr-xr-x 1 root root 27928 May 19 13:46 /snap/swach/19/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot
And it appears the run/user/1000/snap.swach where it saves the screenshot has these permissions:
drwx------ 4 rwwagner90 rwwagner90 100 May 19 14:04 snap.swach
Are these compatible? Any ideas here?
Doing it that way, you bypassed all confinement so it doesn’t test that the snap can run it. You will either need to add an apps: entry to your yaml to expose the scrot executable to test whether it is possible to run it directly, or run it through a shell with:
snap run --shell swach /snap/swach/current/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot
@lucyllewy I tried the command you suggested and It says cannot execute binary file. How might I allow Snap to execute this file?
It seems like if there is a way to allow that binary to run inside Snap, things should work. Please advise on how to give it permissions to run!
@lucyllewy @jdstrand @ogra Here is where the bundled scrot binary from electron-color-picker gets executed https://github.com/mockingbot/electron-color-picker/blob/master/source/linux/linux-scrot/index.js#L7
I wonder if instead of bundling scrot as part of that electron package, if we instead had it try to execute a system installed version, if it would work? I think the problem Snap has is we’re including this random scrot binary it does not know about, so it blocks execution, but what we have to do instead is add scrot to stage packages, and execute that one.
Does that sound correct? Is there any way to whitelist other random binaries?
Is it possible to add the bundled scrot binary to parts or something? I’m not sure how to make it able to run.
Perhaps something like this?
parts:
scrot:
plugin: dump
source: app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot
Just a total shot in the dark there, not really sure how this is supposed to work.
@rwwagner90 - I suggest asking these new questions in the ‘snapcraft’ category so the right eyes are on them and you can hopefully get answers more quickly.