AppImage errs out when /tmp is mounted with noexec

[ilu33]

Linux AppImage errs out when /tmp is mounted with noexec. Tested with v. 2.6.1 and 2.7.0 b2.

./WowUp-2.6.1.AppImage 
A JavaScript error occurred in the main process
Uncaught Exception:
Error: /tmp/.org.chromium.Chromium.gpmxM5: Fehler beim Mappen des Shared Objects
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1800)
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1199:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:5:2027)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:829:12)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13331)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at Object.<anonymous> (/tmp/.mount_WowUp.348rSD/resources/app.asar/app/curse-folder-scanner.js:10:21)
    at Module._compile (node:internal/modules/cjs/loader:1116:14)

/tmp is not a place for executable files on Linux, see http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#TMPTEMPORARYFILES. Mounting /tmp noexec is the correct way to keep the system secure.

Fix: Build the appimage correctly as explained by Electron main dev here, electron/electron#24242 (comment):

"The issue is the app in question is packaging their native modules into an ASAR file (normally app.asar). You can't load a native module from an ASAR so Electron tries to help you out by extracting the native module (effectively a shared library) to the temporary directory and load it from there. In the case where /tmp has noexec this isn't going to work.

Each app should ensure that native modules aren't packed into the ASAR and are instead stored / shipped in app.asar.unpacked."

At least I'm guessing that this is the issue here. If not, I'd have to troubleshoot further.

Edit: As a workaround I tried starting the appimage with a dedicated tmpdir and it worked, so I'm quite sure that the wrong handling of the ASAR is indeed the problem.

[jliddev]

If you find a way to fix this while also continuing to use the electron builder package let me know. We do not manually build the app image the library we use for packaging does.

[ilu33]

Disclaimer: I have absolutely zero experience with Electron.
From reading https://www.electron.build/configuration/configuration.html#AsarOptions and https://www.electron.build/generated/platformspecificbuildoptions I think it's the asarUnpack option which needs to be used to specify the native stuff the Electron dev spoke about. I have no idea what to put there exactly.

"linux": {
  "icon": "electron-build/icon.icns",
  "target": ["AppImage"],
  "asar": true,
  "asarUnpack": ["../app/<something>" ]
}

The tmp directory that I set up for Wowup includes the whole app code, so maybe even set asar to false for Linux platform? I cannot find any asar setting in your electron-builder.json and I'm not sure what the default value is.
I'm willing to test if you provide the appimage.

[CyanoHao]

The AUR package is also affected by noexec flag on /tmp.

I can confirm that the following configuration fixes the AUR package.

  "linux": {
    "icon": "electron-build/icon.icns",
    "target": ["AppImage"],
    "asarUnpack": ["build/Release/addon.node"]
  }

[shawngmc]

Running into this issue via downloaded AppImage file on Fedora 35 as well.

Is the fix above being tested, or is it not a complete fix?

[shawngmc]

The AUR package is also affected by noexec flag on /tmp.

I can confirm that the following configuration fixes the AUR package.

  "linux": {
    "icon": "electron-build/icon.icns",
    "target": ["AppImage"],
    "asarUnpack": ["build/Release/addon.node"]
  }

I've tried running with this fix, but to no avail. The error still shows up, and the UI for the addons for a WoW install is empty.

Mind you, I'm not 100% clear on how to test this. I did the npm install, then 'npm run electron:local'. I've also tried 'npm run electron:build:local', which made an unpacked installation - when run, it gave the same error.

I also couldn't get it working via making a tempdir, at least not via
mkdir -p ./.tmpdir/ && env TMPDIR=./.tmpdir/ ./WowUp.Appimage

Then again, my error is actually slightly different...

When I run the release 2.7.0 AppImage with no special handling:

03:42:17.157 › Error: ERR_FAILED (-2) loading 'file:///tmp/.mount_WowUp-foVoI7/resources/app.asar/dist/index.html'
    at rejectAndCleanup (node:electron/js2c/browser_init:161:7647)
    at EventEmitter.stopLoadingListener (node:electron/js2c/browser_init:161:8022)
    at EventEmitter.emit (node:events:390:28)

When I give it a tmpdir:

03:43:12.089 › Error: ERR_FAILED (-2) loading 'file:///home/shawn/AppImages/.tmpdir/.mount_WowUp-kdi38C/resources/app.asar/dist/index.html'
    at rejectAndCleanup (node:electron/js2c/browser_init:161:7647)
    at EventEmitter.stopLoadingListener (node:electron/js2c/browser_init:161:8022)
    at EventEmitter.emit (node:events:390:28)

So it's not actually the 'failed to map segment from shared object' error. Should I split mine out into a new ticket at this point? It's a different message, but a similar 'AppImage is failing as it can't load resources' error...

[CyanoHao]

@shawngmc

It does fix the AUR package. AppImage is not tested.

As far as I have tested, modify electron-builder.json, or an equivalent command line argument --config.asarUnpack="build/Release/addon.node" can fix it. (The latter one is used in PKGBUILD for its simplicity.)

fig. (1) addon.node is correctly unpacked. (2) WowUp runs while /tmp is mounted with noexec.

[CyanoHao]

The error message “ERR_FAILED (-2) loading ...” may indicate some other things go wrong. Message related to noexec flag should be “failed to map segment from shared object”.

I tried the command mkdir -p ./.tmpdir/ && env TMPDIR=./.tmpdir/ ./WowUp.Appimage with WowUp 2.7.0, and it works on my Arch Linux. WowUp runs successfully, with addon.node correctly extracted with filename .org.chromium.Chromium.<random>. (It's easy to confirm with objdump.)

[ilu33]

Starting the appimage with a dedicated tmpdir works for me too so I'm fairly sure that @shawngmc has another issue. Are you sure that your kernels support for user namespaces is switched on?

@jliddev Did you include CyanoHaos code in your latest build?

[shawngmc]

Starting the appimage with a dedicated tmpdir works for me too so I'm fairly sure that @shawngmc has another issue. Are you sure that your kernels support for user namespaces is switched on?

It's the default Fedora kernel, and I have docker installed and working. I also have has CONFIG_USER_NS=y in the /boot/config, so I'm 99.9% sure it is.

Opened #1169 for my issue.

[jliddev]

Starting the appimage with a dedicated tmpdir works for me too so I'm fairly sure that @shawngmc has another issue. Are you sure that your kernels support for user namespaces is switched on?

@jliddev Did you include CyanoHaos code in your latest build?

I see no PR adding such.

[ilu33]

We provided the fix in code. I should not need to fork a repository just to promote a ONE LINE ONLY code change.

[linaori]

If you open the file in github, there's an edit button and you can quickly propose the change that way

[ilu33]

I did. That automatically generates a fork.

[jliddev]

Can someone give the latest beta build a check to see if it fixes your issue?

[ilu33]

No, it did not :-(
It's not just us with this problem. Element filed an issue electron-userland/electron-builder#6792 and, as a workaround, they use "asarUnpack": "**/*.node" (element-hq/element-desktop#337).
So does https://github.com/jitsi/jitsi-meet-electron/blob/master/package.json.

I did the corresponding PR here #1191.

This is just me doing try and error, I have no way of testing anything before you build.

[jliddev]

@ilu33 Another build is out with that change.

[ilu33]

I think we've got it. Starts up now without the tmpdir workaround. @shawngmc maybe you could test again too?