Properly package native modules

[daenney]

Description

Jitsi Meet will refuse to start if /tmp is mounted with noexec:

Current behavior

A JavaScript error occurred in the main process
Uncaught Exception:
Error: /tmp/.org.chromium.Chromium.6JbPdD: failed to map segment from shared object
    at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1138:18)
    at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2073)
    at Module.load (internal/modules/cjs/loader.js:935:32)
    at Module._load (internal/modules/cjs/loader.js:776:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12684)
    at Module.require (internal/modules/cjs/loader.js:959:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/opt/jitsi-meet-desktop/resources/app.asar/node_modules/robotjs/index.js:1:15)
    at Module._compile (internal/modules/cjs/loader.js:1078:30)

Expected Behavior

Jitsi starts

Possible Solution

electron/electron#24242 (comment)

This issue is solvable (and should be solved) on the apps side of things. 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.

Steps to reproduce

• sudo mount -o remount,noexec /tmp
• jitsi-meet-desktop

Environment details

• Linux: 5.11.11-arch1-1 Simplify rebuilding Node modules for Electron #1 SMP PREEMPT Tue, 30 Mar 2021 14:10:17 +0000 x86_64 GNU/Linux
• Jitsi: 2.8.4

[daenney]

Temporary workaround: TMPDIR=/some/path/without/noexec jitsi-meet-desktop.

[saghul]

Thanks for the report! I think this should be reported to electron-builder, so the bundle is created with the addonss outside of it. This may have some implications when code signing on macOS though.

[csett86]

@daenney Is this happening with the AppImage or with the debian package (or both)?

For mac there was a similar issue (in that case preventing macOS signing of the native addons) and I fixed this via asarUnpack in the mac section: https://github.com/jitsi/jitsi-meet-electron/blob/master/package.json#L47
That could be a solution for linux as well...

[daenney]

The AppImage. I'm using the AUR package for it

[daenney]

The odd thing is, the documentation suggests all of this should be already happening for you: https://www.electron.build/generated/platformspecificbuildoptions

asar = true AsarOptions | Boolean - Whether to package the application’s source code into an archive, using Electron’s archive format.
Node modules, that must be unpacked, will be detected automatically, you don’t need to explicitly set asarUnpack - please file an issue if this doesn’t work.

But at least setting asarUnpack for the AppImage too sounds like it would fix the issue.

[saghul]

The AUR module unpacks the AppImage (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jitsi-meet-desktop-bin), so I'd say it's up to them to address this.