Electron: Die SUID-Sandbox-Helper-Binärdatei wurde gefunden, ist aber nicht richtig konfiguriert

Leider können wir dies nicht automatisch richtig konfigurieren, da das Setzen der entsprechenden Berechtigungen Root-Rechte erfordert und wir während npm install nicht nach einem Root-Passwort fragen möchten.

Im Idealfall würde Arch seine Kernel-Unterstützung für unprivilegierte CLONE_NEWUSER konfigurieren und Chromium (und Electron) könnten die Namespace-Sandbox verwenden, anstatt sich auf die alte setuid-Sandbox zu verlassen. Apps, die unter Linux verteilt werden, müssen dies in ihren Installationsprozess integrieren. Siehe zum Beispiel https://github.com/electron-userland/electron-installer-debian/pull/184 und https://github.com/electron-userland/electron-installer-redhat/pull/112 .

Während der Entwicklung sollten wir wahrscheinlich etwas auf npm install ausgeben, allerdings mit Anweisungen, wenn wir feststellen, dass die Namespace-Sandbox nicht verfügbar ist.

Hey, danke für die superschnelle Antwort!

Kommt der unprivilegierte CLONE_NEWUSER aus CONFIG_USER_NS=y ? Wenn ja, sollte das die aktuelle Konfiguration sein.

Bitte lassen Sie mich wissen, ob ich etwas tun kann, um zu helfen, oder wenn dies auf Arch erwartet wird, schließe ich gerne lösen Sie dies in PKGBUILD anstatt zu erwarten, dass es direkt aus npm perfekt funktioniert. Beifall!

CONFIG_USER_NS=y aktiviert die Funktion für Benutzernamensräume, aber sie sind standardmäßig immer noch auf privilegierte Benutzer beschränkt. Dies schlägt vor, sysctl kernel.unprivileged_userns_clone=1

Gibt es in der Zwischenzeit eine mögliche Problemumgehung, bis jede Linux-Distribution diese Funktionen aktiviert?

@kitingChris Die setuid-Sandbox IST die Problemumgehung. Sie müssen nur sicherstellen, dass Ihre Entwicklungs- / Verpackungsskripte beim Entwickeln / Freigeben einer Elektron-App die Berechtigungen des Sandbox-Helfers korrekt wie oben verlinkt

Gibt es in der Zwischenzeit eine mögliche Problemumgehung, bis jede Linux-Distribution diese Funktionen aktiviert?

Siehe die ursprüngliche Nachricht:

Wenn ich die Datei chown und chmod, funktioniert es einwandfrei

Siehe auch hier https://github.com/electron/electron/issues/16631#issuecomment -476082063 Damit die Suid-Sandbox funktioniert, müssen Sie die Binärdatei chrome-sandbox diese Weise optimieren:

• sudo chown root chrome-sandbox
• chmod 4755 chrome-sandbox

Das Problem ist jedoch schwerwiegender, wenn Sie appimage/snap-Pakete ausführen. Ich habe noch keine anständige Problemumgehung für diese Fälle offenbart. Es funktioniert, wenn appimage mit --no-sandbox Argument ausgeführt wird, aber dies ist ein Hack.

@nornagon

weil das Setzen der entsprechenden Berechtigungen Root-Rechte erfordert und wir während der npm-Installation nicht nach einem Root-Passwort fragen möchten.

Das Ausführen von chmod 4755 node_modules/electron/dist/chrome-sandbox erfordert keine Root-Berechtigung und das sollte ausreichen, um einen solchen Befehl zum Umschließen der App in deb/pacman/etc-Pakete auszuführen, wie wenn solche Pakete normalerweise alle Dateien einschließlich chrome-sandbox installiert werden im Besitz von root. Es wäre also toll, dass Elektron chmod 4755 node_modules/electron/dist/chrome-sandbox automatisch während des Installationsprozesses macht, da dann dieser Fall nicht wie hier erwähnt manuell bearbeitet werden muss.

CONFIG_USER_NS=y aktiviert die Funktion für Benutzernamensräume, aber sie sind standardmäßig immer noch auf privilegierte Benutzer beschränkt. Dies schlägt vor, sysctl kernel.unprivileged_userns_clone=1

Ich bestätige, dass die Ausführung von sudo sysctl kernel.unprivileged_userns_clone=1 eine weitere Problemumgehung ist, verwandter Kommentar .

@vladimiry Ich musste zuerst chown und dann chmod. Umgekehrt hat es nicht funktioniert.

@burningTyger du hast recht , ich habe gerade die ursprüngliche Nachricht geändert.

@nornagon Wenn wir chmod 4755 out/Release/chrome-sandbox auf CI haben, wird diese Berechtigung beibehalten, wenn wir chmod 4755 out/Release/chrome-sandbox zip es oben haben, oder müssen wir diese Änderung in electron-download vornehmen, um die Berechtigung für DL zu korrigieren?

Das gleiche hier ist eine schlechte neue Funktion für das, was geändert werden muss ... :(

@MarshallOfSound zip unterstützt keine Berechtigungen, aber letztendlich ist das Problem nicht die chmod-Berechtigung, sondern der Besitzer. Der setuid-Sandbox-Helper ist suid _to root_, da er Funktionen ausführen muss, die nur root zur Verfügung stehen. Wenn es möglich wäre, die entsprechenden Berechtigungen zu setzen, ohne zuvor Root-Rechte zu erlangen, wäre das eine sehr gravierende Schwachstelle in Linux. Zum Glück für Linux und leider für uns ist das nicht der Fall.

Hier sind die Optionen, wie ich sie sehe:

1. Ändere nichts in Electron. Empfehlen Sie Entwicklern, unprivilegierte CLONE_USERNS auf ihrem Kernel zu aktivieren, damit die Namespace-Sandbox anstelle der setuid-Sandbox ausgeführt werden kann.
2. Booten ohne Sandbox, wenn keine Sandboxing-Methode verfügbar ist _nur beim Booten einer nicht gepackten App_. Wenn Electron eine gepackte App bootet, weigern Sie sich, ohne Sandbox zu booten.
3. Wenn keine Sandboxing-Methode verfügbar ist, booten Sie in allen Fällen ohne Sandboxing und drucken Sie eine Warnung.
4. Deaktivieren Sie Sandboxing standardmäßig unter Linux.

Ich tendiere zu (2). Dies würde die Entwicklung vereinfachen, ohne die Sicherheit der bereitgestellten App zu beeinträchtigen.

Ich bin mir noch nicht sicher, was ich mit Snap/Flatpak machen soll, da ich mit ihrer Funktionsweise nicht vertraut bin. Es ist möglich, dass sie die App bereits ausreichend sandboxen, sodass wir das Sandboxing in dieser Situation vollständig deaktivieren können, wie wir es beim Erstellen der Mac App Store-Version von Electron tun.

Im Moment mag ich eher die erste Option.

1. Booten ohne Sandbox, wenn keine Sandboxing-Methode verfügbar ist, nur beim Booten einer nicht gepackten App. Wenn Electron eine gepackte App bootet, weigern Sie sich, ohne Sandbox zu booten.

Ein solches Szenario wäre irgendwie irreführend. Eine entpackte App kann ohne Sandboxing erfolgreich ausgeführt werden, aber es besteht die Möglichkeit, dass die verpackte App mit aktiviertem Sandboxing nicht auf dieselbe Weise funktioniert. Wie zum Beispiel der Fall, wenn Sie vom Renderer-Prozess aus auf den Hauptprozess zugreifen, nicht über die remote Schnittstelle. Oder der Fall, dass die App in AppImage / Snap / Flatpak-Pakete verpackt wird.

1. Wenn keine Sandboxing-Methode verfügbar ist, booten Sie in allen Fällen ohne Sandboxing und drucken Sie eine Warnung.

Eine verpackte App, die als Sandbox konzipiert und entwickelt wurde, kann also ohne Sandbox ausgeführt werden, wenn keine Sandbox verfügbar ist. Das hört sich für mich nicht gut an.

1. Deaktivieren Sie Sandboxing standardmäßig unter Linux.

Was bedeutet es genau? Wie kann Sandboxing unter Linux so aktiviert werden, dass die App entweder startet oder fehlschlägt, wenn kein Sandboxing verfügbar ist (die aktuelle Situation, erzwungenes Sandboxing).

Ich mag (1) auch, aber um (2) ein wenig zu verteidigen, würde sich die der App ausgesetzte API beim Deaktivieren der Sandbox nicht ändern. Das einzige, was wir deaktivieren würden, ist die Sandbox auf Betriebssystemebene. Wir würden die App immer noch auf die gleiche Weise laden, sie wäre nur nicht durch das Betriebssystem geschützt.

Wir würden die App immer noch auf die gleiche Weise laden, sie wäre nur nicht durch das Betriebssystem geschützt.

Dann hört es sich für mich auch gut an. Danke für die Erklärung.

Ich mag 2. nicht, weil optionale Sicherheit im Allgemeinen dazu führt, dass Leute die Sicherheit deaktivieren.

Wenn ich jetzt in die Schuhe des "dummen Benutzers" schlüpfe, würde ich lieber sehen, dass Electron standardmäßig funktioniert. Wenn es sich um eine sehr wichtige Sicherheitsmaßnahme handelt, geben Sie mir eine Warnung und eine gute Erklärung, warum ich zusätzliche Arbeit leisten muss. Wenn es nicht so wichtig ist, dann gib mir nicht den schlechten "es geht nicht"-Geschmack.

Aus diesem Grund mag ich 1. (mit einer erzwungenen Beendigung, wie jetzt) ​​oder 4.

:x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox wirft einige Warnsignale für mich.

Um es ganz klar zu sagen: Es setzt das SUID-Bit auf chrome-sandbox , wodurch _jeder Benutzer_ in der Lage ist, die Datei _als root_ auszuführen. Dies bedeutet, dass jeder Benutzer root werden kann, wenn es eine Möglichkeit gibt, chrome-sandbox böswillig zu verwenden oder der Inhalt jemals bösartig wird. chrome-sandbox wäre ein sehr interessantes Angriffsziel.

Ich rate dringend davon ab, diese Problemumgehung auf npm install , da sie sudo erfordern würde (Benutzer muss ein Passwort eingeben), sie invasiv ist und wir die Sicherheitsfolgen möglicherweise nicht verstehen.

chown root:root chrome-sandbox && chmod 4755 chrome-sandbox wirft einige rote Fahnen für mich auf.

Natürlich tut es das. Aber Sie können User Namespace Sandboxing als Alternative aktivieren sudo sysctl kernel.unprivileged_userns_clone=1 (standardmäßig aktiviert auf Ubuntu, aber nicht auf Arch).

Nur um ganz klar zu sagen, was es tut: Es setzt das SUID-Bit auf chrome-sandbox , wodurch _jeder Benutzer_ in der Lage ist, die Datei _als root_ auszuführen. Dies bedeutet, dass jeder Benutzer root werden kann, wenn es eine Möglichkeit gibt, chrome-sandbox böswillig zu verwenden oder der Inhalt jemals bösartig wird. chrome-sandbox wäre ein sehr interessantes Angriffsziel.

Ja, aber auch diese Binärdatei ist genau die gleiche, die mit Chrome geliefert wird. Wenn Sie sich also Sorgen machen, sollten Sie Chrome wahrscheinlich auch deinstallieren :)

Gibt es eine Möglichkeit, ohne die Sandbox auszuführen / ohne den "Sandbox-Helfer" auszuführen? Haben sich die ersten Benutzer beschwert 😅
Ich habe erwartet, dass dies die Sandbox deaktiviert, aber immer noch den Fehler The SUID sandbox helper binary was found, but is not configured correctly .
Ich würde es hassen, zu Elektron 4.x zurückzukehren 🤨

Fehlermeldung

Snapcraft Review & suid

Ich habe versucht, einen Snap mit Suid-Flag auf chrome-sandbox hochzuladen, aber der Überprüfungsprozess von Snapcraft verbietet die Verwendung von Suid-Flags.

The store was unable to accept this snap.
  - checksums do not match. Please ensure the snap is created with either 'snapcraft pack <DIR>' (using snapcraft >= 2.38) or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs -no-fragments'. If using electron-builder, please upgrade to latest stable (>= 20.14.7). See https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/17 for details.
  - found errors in file output: unusual mode 'rwsr-xr-x' for entry './chrome-sandbox'

@thomasnordquist zum Deaktivieren von Sandboxing --no-sandbox Betriebssystemebene app.commandLine.appendSwitch wird nicht ausreichen. In Bezug auf ein Snap-Paket möchten Sie vielleicht versuchen, einen Plug wie hier beschrieben hinzuzufügen. Ich bin mir nicht sicher, ob das hilft, da ich es noch nicht ausprobiert habe, wäre großartig, wenn Sie dies tun. Im Moment bevorzuge ich es, die App, die ich erstellt habe, im gemischten Modus zu veröffentlichen : smile:. Electron v5 wird für alle Pakete außer AppImage und Snap verwendet, da noch nicht ganz klar ist, wie diese Pakete mit aktiviertem Sandboxing gut funktionieren, aber es wird irgendwann klar sein.

Wenn Snapcraft Suid-Flags verbietet, besteht wahrscheinlich die einzige Möglichkeit darin, Electrons Sandboxing vollständig in Snapcraft zu deaktivieren und sich auf den Container zu verlassen, den Snapcraft verwendet. Ich bin mir nicht sicher, wie das am besten geht – ist es möglich, beim Packen über Snapcraft zusätzliche Befehlszeilen-Flags anzugeben? Wenn ja, könnten wir das Flag --no-sandbox hinzufügen. Wenn nicht, müssen wir möglicherweise einen bestimmten Erkennungsmechanismus hinzufügen, um die Ausführung in Snapcraft/Flatpak zu erkennen und Sandboxing basierend auf dieser Erkennung zu deaktivieren.

Einige Snap-bezogene Dokumentation https://docs.snapcraft.io/browser-support-interface

@posix4e können Sie das Problem der Ausführung des Sandkasten-Snap-Pakets sowohl im Benutzernamensraum- als auch im SUID-Sandbox-/Fallback-Modus beleuchten? Sieht so aus, als hättest du Erfahrung mit dem Optimieren der Snap-Konfiguration des Brave Browsers. CC @flexiondotorg.

Nur um ganz klar zu sagen, was es tut: Es setzt das SUID-Bit auf chrome-sandbox , wodurch _jeder Benutzer_ in der Lage ist, die Datei _als root_ auszuführen. Dies bedeutet, dass jeder Benutzer root werden kann, wenn es eine Möglichkeit gibt, chrome-sandbox böswillig zu verwenden oder der Inhalt jemals bösartig wird. chrome-sandbox wäre ein sehr interessantes Angriffsziel.

Ja, aber auch diese Binärdatei ist genau die gleiche, die mit Chrome geliefert wird. Wenn Sie sich also Sorgen machen, sollten Sie Chrome wahrscheinlich auch deinstallieren :)

Ich bin teilweise besorgt darüber, dass eine Binärdatei von Chrome root:root mit SUID-Satz hat, ja. Sehr wenig Code ist ohne Fehler. Hier ist der Quellcode für die Aufzeichnung: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Aber ich mache mir mehr Sorgen, wenn npm install würde:

1. Laden Sie eine Reihe von Software on-the-fly herunter.
2. Erstellen Sie automatisch eine der Dateien root:root und SUID.

Ich denke, das wäre der erste Software-Stack, den ich kenne, der automatisch sudo chown root:root && sudo chmod 4755 auf eine Datei ausführt, die einem Nicht-Root-Benutzer gehört.

Ein sudo chown root:root && sudo chmod 475 bei der npm-Installation sollte nicht in Frage kommen, npm müsste als Root ausgeführt werden, um die Berechtigungen festzulegen. Das Hook-Modell von npm würde es allen installierten Paketen ermöglichen, ihre Hooks ebenfalls als Root auszuführen. Bei möglicherweise Hunderten von Paketen und verschachtelten Abhängigkeiten wäre dies sehr gefährlich.

Das Ausführen eines sudo chown root:root && sudo chmod 475 auf npm install sollte nicht in Frage kommen

Dies wird meines Wissens nicht als Option angesehen.

Ich stimme zu, dass alles, was während der npm-Installation Root-Rechte erfordert, ein Nichtstarter ist. Deshalb habe ich es nicht als eine der Optionen aufgeführt .

electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0 und electron-installer-snap 3.2.0 wurden mit den SUID-Sandbox-Änderungen veröffentlicht. Electron Forge v5 und v6 Beta sollten auch vorübergehend aktualisiert werden (über In-Range-Versionsupdates verwenden Sie entsprechend npm update oder yarn upgrade ).

Zur Verdeutlichung einfach den zugehörigen Code verlinken.

Nur um es klarzustellen, für Snaps war mehr drin (nämlich das Hinzufügen von Browser-Sandbox-Unterstützung, wie oben erwähnt). Weitere Informationen finden Sie in den Änderungen der

Ich habe gerade darauf geklickt, chown / chmod funktioniert, aber das ist nicht die einzige erforderliche Aktion, wenn Sie in einem Docker-Image ausführen.

Wenn Sie dies tun, erhalten Sie einen weiteren Fehler:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Die Lösung dafür besteht darin, --privileged zum Befehl docker run hinzuzufügen. Ich glaube nicht, dass dies eine gute Lösung ist, hauptsächlich auf CI.

@JCMais es hört sich so an, als würde Electron fälschlicherweise versuchen, die Namespace-Sandbox im Docker zu verwenden, obwohl es versuchen sollte, die suid-Sandbox zu verwenden. Ich bin mir nicht sicher, warum das so ist, aber Sie können die suid-Sandbox mit --disable-namespace-sandbox erzwingen. Wenn Sie Docker mit --privileged (oder --cap-add SYS_ADMIN oder einem benutzerdefinierten Seccomp-Profil, das CLONE_NEWUSER zulässt) starten, sind Namespaces in der Sandbox verfügbar und es besteht keine Notwendigkeit für die setuid-Sandbox oder ihre ausführbare Hilfsdatei .

Wie @thomasnordquist habe ich das Sandboxing für Snap/AppImage-Pakete mit einem Preload-Skript --no-sandbox . Es ist bequem mit dem after-pack Skript von Electron-Builder

@nornagon wie genau soll ich dieses Flag an Elektron übergeben? Ich habe versucht, nur --disable-namespace-sandbox hinzuzufügen, aber es gibt immer eine Fehlermeldung:

:~$ electron --disable-namespace-sandbox
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Kann bestätigen, dass mich dies im Handumdrehen zerstört hat und alle unsere Linux-Benutzer auf einer alten Version stecken, bis ich das beheben kann.

Ich bin VÖLLIG für eine Möglichkeit, die Sicherheit zu verbessern, aber dies wurde ohne ein Feature-Flag zum Deaktivieren geliefert.

Ich möchte auch argumentieren, dass dies nicht ohne eine Funktion zum Deaktivieren per Code hätte ausgeliefert werden sollen. Ich schätze, dies war jedoch möglicherweise versehentlich, da --no-sandbox nicht funktioniert, es sei denn, es wird manuell über die Befehlszeile eingegeben.

Wenn etwas mit der Implementierung der Sandbox-Unterstützung von electron-installer-snap stimmt, teilen Sie mir dies bitte in der Problemverfolgung mit.

Wenn etwas mit der Implementierung der Sandbox-Unterstützung von electro-installer-snap nicht stimmt, teilen Sie mir dies bitte im Issue Tracker mit.

Ich würde auch gerne hören, dass jemand bestätigt, dass die Änderung ausreicht, um das Problem mit Snap-Paketen zu lösen. Daher sind sowohl positive als auch negative Rückmeldungen willkommen. Siehe zugehörige Informationen .

@vladimiry Ich habe das getestet und es hat nicht funktioniert.

Ich benötige eine Lösung, die sich nicht um OS-Patches, sysctl oder Neustarts herum auflöst. Ich brauche etwas, das jetzt funktioniert. --no-sandbox wäre vorzuziehen.

Es wäre für mich viel hilfreicher, wenn jemand eine minimale Electron-App bereitstellen könnte, mit der ich den nicht funktionierenden verpackten Snap reproduzieren könnte. Ich habe einen Fork von electron-quick-start , um einen Snap in CircleCI zu erstellen und ihn auf meinem (Debian Stretch) Laptop installiert, um zu überprüfen, ob meine Änderungen zumindest eine funktionierende Electron-App erstellt haben.

"Hat nicht funktioniert" hilft mir nicht herauszufinden, was ich in electron-installer-snap tun kann, damit es für andere richtig verpackt wird.

@burtonator , danke für das Testen des Zeugs. Soweit ich weiß, ist das Paket in das Snap/AppImage-Build-Loader-ähnliche bash/sh-Skript, das die ursprüngliche Binärdatei/Elektron mit --no-sandbox cmd-Argument startet, derzeit die einzige verifizierte Problemumgehung.

@malept Bevor Sie das Zeug testen, müssen Sie die User Namespace OS-Funktion deaktivieren, indem Sie sudo sysctl kernel.unprivileged_userns_clone=0 ausführen.

@vladimiry Ja, mein Laptop hat diese Benutzereinstellung bereits.

Wenn jemand nach einer Lösung dafür sucht, sieh dir die Lösung von @thomasnordquist oder meine Adaption davon an. Sie funktionieren, indem sie die Sandbox unter Linux deaktivieren.

@fabiospampinato Ihre Anpassung deaktiviert die Sandbox für alle Linux-Pakettypen, aber zumindest DEB- und Pacman-Pakete funktionieren gut mit SUID-Sandbox (wahrscheinlich alle nicht containerähnlichen Pakete), es muss nur das SUID-Berechtigungsbit auf chrome-sandbox binär. Setzen Sie jedoch kein SUID-Berechtigungsbit für das Snap-Paket, da Snap Store solche Arten von Paketen ablehnt. Also setze ich das SUID-Bit für alle Linux-Pakete, die Snap/AppImage-Pakete erwarten, die Sandboxing deaktivieren, verwandter Code .

CONFIG_USER_NS=y aktiviert die Funktion für Benutzernamensräume, aber sie sind standardmäßig immer noch auf privilegierte Benutzer beschränkt. Dies schlägt vor, sysctl kernel.unprivileged_userns_clone=1

Ich bestätige, dass die Ausführung von sudo sysctl kernel.unprivileged_userns_clone=1 eine weitere Problemumgehung ist, verwandter Kommentar .

Danke Kumpel, arbeite für mich! @vladimiry

Weißt du, ob es jetzt mit 5.0.2 funktioniert?

@p3x-robot Dieses Problem wird im Changelog nicht erwähnt. Zur Sicherheit gerade nachgeschaut und der Fehler ist bei mir immer noch da.

@rybaczewa danke für die Antwort, ich

kann es kaum erwarten bis v5 läuft

v5 funktioniert

Um den Leuten in diesem Thread @p3x-robot @rybaczewa klar zu

Wenn diese Protokollmeldung angezeigt wird, müssen Sie entweder sudo sysctl kernel.unprivileged_userns_clone=1 ausführen oder der Binärdatei chrome_sandbox die richtigen Berechtigungen erteilen, wie in der Fehlermeldung beschrieben.

@vladimiry @MarshallOfSound warum sudo sysctl kernel.unprivileged_userns_clone=1 noch chrome_sandbox v5.0.x installieren. Ich kann nur mit v4.xx installieren

Sie denken, ein Benutzer wird sudo ? Sie werden dieses Programm für schlecht halten und die App deinstallieren.
Die Versionen v5 oder v6 oder v7 funktionieren nicht richtig, daher ist dies ein Fehler :

@p3x-robot snap Unterstützung wie oben angegeben hängt davon ab, wie Sie den Snap erstellen. electron-installer-snap unterstützt dies sofort und wie oben erwähnt, wenn dieses Modul Probleme hat / nicht funktioniert, melden Sie bitte ein Problem mit diesem Modul.

Weitere Informationen finden Sie im electron-installer-snap Repository oder in den

Um es noch einmal zu wiederholen, mein derzeitiges Verständnis hier ist, dass kein Fehler behoben werden muss, die Sandbox von Electron funktioniert wie erwartet. Was hier diskutiert wird, sind Probleme, mit denen die Leute beim Verpacken der chrome_sandbox Binärdatei konfrontiert sind

Das ist seltsam, weil ich bereits Sandbox hinzugefügt habe:

app.enableSandbox()
app.commandLine.appendSwitch('no-sandbox')

Ausgang:

patrikx3<strong i="9">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ /snap/bin/p3x-redis-ui 
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
[12999:0525/085646.618618:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /snap/p3x-redis-ui/5/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)
patrikx3<strong i="10">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ 

Ich versuche dies als: app.enableSandbox() , aber ich bekomme:

Uncaught ReferenceError: require is not defined
    at onload.js:1

Wenn ich die Zeile entferne, funktioniert es.

@MarshallOfSound ich verwende electron-builder

Für euch alle, wenn ihr es zum Laufen bringen wollt, habe ich einen Helfer erstellt:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
Wenn Sie electron-builder , fügen Sie es wie folgt hinzu:

Für euch alle, wenn ihr es zum Laufen bringen wollt, habe ich einen Helfer erstellt:

Eine solche Lösung wurde in dieser Themendiskussion bereits oft erwähnt, deshalb habe ich zuvor geschrieben, dass Elektron v5 funktioniert.

@vladimiry danke, ich habe diese Lösung verpasst, ich habe nur eine native JavaScript-Lösung anstelle von Typoskript hinzugefügt ...

Das einzige Problem ist, dass, wenn ich dies nach dem Pack-Hack habe, nicht das Symbol von Electron auf dem Panel verwendet wird, sondern ein zweites Symbol generiert wird. Wie kann das gelöst werden? Ich denke, es ist die No-Sandbox-Flagge. jeder?

es passiert nur mit dem --no-sandbox :

@fabiospampinato Ihre Anpassung deaktiviert die Sandbox für alle Linux-Pakettypen, aber zumindest DEB- und Pacman-Pakete funktionieren gut mit SUID-Sandbox (wahrscheinlich alle nicht containerähnlichen Pakete), es muss nur das SUID-Berechtigungsbit auf chrome-sandbox binär. Setzen Sie jedoch kein SUID-Berechtigungsbit für das Snap-Paket, da Snap Store solche Arten von Paketen ablehnt. Also setze ich das SUID-Bit für alle Linux-Pakete, die Snap/AppImage-Pakete erwarten, die Sandboxing deaktivieren, verwandter Code .

Weißt du, wie ich ein Symbol anstelle von zwei behalten kann?

https://github.com/electron-userland/electron-builder/issues/3872

https://github.com/patrikx3/onenote/issues/65

@p3x-robot gibt es eine Möglichkeit, das Argument --no-sandbox der in Snap verpackten Container-App hinzuzufügen, ohne ein Preloader-ähnliches Bash/sh-Skript einzuführen:

• Entpacken Sie zuerst den Snap, indem Sie unsquashfs your-snap-file.snap ausführen.
• Bearbeiten Sie ./squashfs-root/command.sh indem Sie dort die erforderlichen Argumente hinzufügen.
• Packen Sie den Ordner ./squashfs-root zurück in das Snap-Paket, indem Sie den Befehl snapcraft pack ./squashfs-root ausführen.

Ich habe es nicht versucht, aber ich denke, die ähnliche Repackaging-Aktion kann auch auf das AppImage-Paket angewendet werden, dh es müssen verschiedene Unpack/Pack-Befehle ausgeführt werden.

Ich denke, die beschriebenen Repackaging-Aktionen können in afterAllArtifactBuild Electron-Builder's Hook ausgelöst werden.

@vladimiry danke, soviel, für das eine ist interessant für das afterAllArtifactBuild, ich werde versuchen, die command.sh ohne zu entpacken zu ändern, aber es ist für morgen, danke nochmal!

der eine ist interessant für den afterAllArtifactBuild

@p3x-robot afterAllArtifactBuild Hook wird tatsächlich nicht wie erwartet ausgelöst, aber es ist ziemlich einfach, den Snap oder die Erstellung eines anderen Pakettyps programmgesteuert auszulösen. Sehen Sie hier das Codebeispiel. snapFile ist hier die Ergebnisdatei, also können Sie sie dann entpacken/ unsquashfs , die erforderlichen Änderungen vornehmen und zurückpacken/ snapcraft pack . Im Beispielcode packe ich die Hunspell-Wörterbücher in den ./usr/share/hunspell Ordner des Snaps.

@vladimiry Ich verwende nur Electron v4, da das funktioniert. Ich denke, jemand wird das beheben.

@p3x-robot Ich neige immer noch dazu zu denken, dass man zugeben muss, dass es nichts zu reparieren gibt.

@vladimiry es gibt nichts zu reparieren,

Weiß jemand, ob Electron v5.0.2 mit dem Sandbox-Problem arbeitet?

Es ist wie bei v.5.0.0 :smile:

Ich hoffe, das ist kein Thema, aber für AppImages auf Debian (9) bekomme ich den Fehler:

The setuid sandbox is not running as root. 

Korrigieren Sie mich, wenn ich falsch liege, aber ich verstehe (hauptsächlich aus dieser Diskussion), dass dies durch die deaktivierte Funktion für Benutzernamensräume verursacht wird, die unter Debian standardmäßig deaktiviert ist.

Also zu diesem Vorschlag:

1. Ändere nichts in Electron. Empfehlen Sie Entwicklern, unprivilegierte CLONE_USERNS auf ihrem Kernel zu aktivieren, damit die Namespace-Sandbox anstelle der setuid-Sandbox ausgeführt werden kann.

Ich möchte den Benutzern eine Nachricht anzeigen, die besagt, dass dies nur funktioniert, wenn die Funktion für Benutzernamensräume aktiviert ist (mit möglicherweise einem Hinweis, wie es geht) und vorschlagen, das .deb-Paket als Alternative zu verwenden.

Wie könnte ich eine solche Meldung implementieren, bevor der Fehler angezeigt wird? Gibt es eine Möglichkeit, dem AppRun des AppImage ein benutzerdefiniertes Skript voranzustellen, ohne es zu entpacken und neu zu packen?

Gibt es eine Möglichkeit, dem AppRun des AppImage ein benutzerdefiniertes Skript voranzustellen, ohne es zu entpacken und neu zu packen?

@gcascio Es gab Nachrichten im Thread über die Verwendung eines loader-ähnlichen sh-Skripts, das per Afterpack- Skript injiziert werden

Danke für deine Antwort. Aber ich denke, dass der generierte AppRun nicht verfügbar ist, wenn afterpack aufgerufen wird oder irre ich mich, zumindest finde ich ihn nicht in appOutDir ?

Ich denke, dass der generierte AppRun nicht verfügbar ist, wenn Afterpack aufgerufen wird

Ich habe über die Verwendung eines laderartigen sh-Skripts geschrieben, aber nicht über das Patchen des AppRun-Skripts. Wenn Sie das AppRun-Skript patchen möchten, scheint dies ohne Neupaketieren keine Möglichkeit zu geben.

Ok richtig hab ich falsch verstanden. Ich werde vielleicht mit dem Umpacken gehen, dann danke.

Ich werde vielleicht mit dem Umpacken gehen, dann danke.

@gcascio für den Fall, dass Sie eine Vorlage benötigen.

ia der gleiche Fehler "Die SUID-Sandbox-Helper-Binärdatei wurde gefunden", jedoch in der Snap-Datei nach der Installation
wie kann man das beheben

@vladimiry Ich arbeite in einem Online-IDE-Docker namens http://gitpod.io , auf dem ein Debian-Container läuft. Ich kann das Chrome-Sandbox-Problem nicht beheben, da ich keinen Sudo-Zugriff habe. Der allgemeine Ton hier ist, dass dies ein Chrome-Problem und kein Electron-Problem ist, aber wenn Electron das Problem lösen könnte, wäre das nicht eine gute Sache?

Auf dieser Seite https://www.gitpod.io/blog/gitpodify/ habe ich eine Lösung für die Verwendung von Puppeteer im Container gesehen.

const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});

Könnte Electron einen solchen Code ausprobieren, wenn der Sandbox-Fehler auftritt, bevor der Prozess beendet wird? Oder könnte ich das mit einer Bash-Datei aufrufen?

Könnte Electron einen solchen Code ausprobieren, wenn der Sandbox-Fehler auftritt, bevor der Prozess beendet wird? Oder könnte ich das mit einer Bash-Datei aufrufen?

Ja, das Übergeben des Arguments --no-sandbox an die Binärdatei der Elektron-App im Allgemeinen sollte das Problem umgehen.

Je nach Installationspaket Sie die SUID Berechtigungs - Bit (4755) eingestellt werden könnte chrome-sandbox binary (für Pakete wie deb, Pacman, etc.) oder codieren die --no-sandbox Argument für den Lader sh / Bash - Skript (für Pakete wie Snap und AppImage). Dies ist, was ich derzeit mache, und daher müssen die App-Benutzer nichts tun (kein Sudo-Zugriff erforderlich).

Die neueste Version des Electron-Builder enthält bereits eine Hardcodierung des Arguments --no-sandbox , jedoch nur für das Snap-Paket.

Danke @vladimiry electron --no- lösen . Ich werde auch SNAP auschecken.

es gibt neuere Elektronen-Builder, aber das AppImage ist immer noch nicht repariert, richtig?

Behebt Elektron 6 den Sandbox-Fehler? Ich bin immer noch auf v4, da ich dies nicht beheben kann, weder 5 noch 6.

Hier ist die Situation:

• Electron v5 ermöglichte Mixed-Mode-Sandboxing (dh einige Prozesse werden sandboxiert und andere nicht) unter Linux. Dies ändert nicht, ob Ihre Renderer-Prozesse standardmäßig in einer Sandbox ausgeführt werden, es bedeutet jedoch, dass der GPU-Prozess jetzt in einer Sandbox ausgeführt wird.
• Die Sandbox von Chromium unter Linux verwendet eine Betriebssystemfunktion namens CLONE_NEWUSER . Einige Kernel sind mit dieser Funktion ausgestattet, die aus Vorsicht auf privilegierte Benutzer beschränkt ist. Sie können mehr darüber lesen Sie hier [lwn, 2016].
• Wenn CLONE_NEWUSER nicht verfügbar ist, greift Chromium auf die Verwendung eines anderen Sandboxing-Mechanismus zurück, der eine Hilfs-Binärdatei erfordert, die setuid zum Rooten ist. Wenn diese Binärdatei nicht vorhanden ist oder nicht über die richtigen Berechtigungen verfügt ( 4755 _und im Besitz von root_), kann die Sandbox nicht booten.
• Das Setzen der Berechtigungen für die Helfer-Binärdatei muss von einem privilegierten Benutzer (zB root) vorgenommen werden. Wir setzen diese Berechtigungen nicht auf npm install , da wir während npm install keinen Root-Zugriff anfordern möchten.
• Die Release-Pakete von Electron v5 enthalten die Hilfs-Binärdatei, aber es liegt an den verschiedenen Paketierungs- und Verteilungstools, sicherzustellen, dass sie die richtigen Berechtigungen und das richtige Eigentum erhält.

Es gibt zwei Problemumgehungen:

1. Aktivieren Sie den unprivilegierten Zugriff auf CLONE_NEWUSER in Ihrem Kernel. Einige Kernel unterstützen die Änderung mit sysctl kernel.unprivileged_userns_clone=1 .
2. Deaktivieren Sie Sandboxing vollständig, indem Sie mit --no-sandbox starten. Dieses Argument von JS hinzuzufügen reicht leider nicht aus, da der GPU-Prozess gestartet wird, bevor der Hauptprozess JS ausgeführt wird.

Das automatische Deaktivieren der Sandbox in Electron wird nicht unterstützt, wenn diese Bedingungen erkannt werden. Sie müssen sicherstellen, dass Ihre verteilten Pakete die entsprechenden Berechtigungen festlegen. Die meisten Tools (zumindest Electron-Builder, Electron-Installer-Snap, Electron-Installer-Debian und Electron-Installer-Redhat) unterstützen dies automatisch und erfordern keine Konfiguration durch den Entwickler. Wenn Sie ein anderes Tool verwenden, das dies nicht unterstützt, melden Sie bitte ein Problem mit diesem Tool und verlinken Sie zu diesem Kommentar.

Ich schließe dieses Thema, weil wir, wie im vorherigen Absatz erwähnt, die Anforderung nicht ändern werden, dass Electron in der Produktion Zugriff auf eine funktionierende Sandbox benötigt, sofern nicht ausdrücklich anders angegeben. Um die Entwicklung zu erleichtern, habe ich jedoch #19550 geöffnet, um die Option zu verfolgen, automatisch in den Nicht-Sandbox-Modus zu degradieren, wenn Electron über npm install installiert wird, anstatt über ein verteiltes Paket.

@ p3x-Roboter können Sie ein minmal Beispiel für die Problemumgehung finden 2. von @nornagon erwähnt hier die von @vladimiry inspiriert

@gcascio, aber ich kann den Snap-Hack entfernen, oder? wie der Snap im Electron Builder berechnet wird, können Sie das bestätigen?

@gcascio es funktioniert, vielen Dank! Es klappt!

@gcascio kein Workie, es generiert 2 Icons, also bin ich zu Electron v4.2.8 zurückgekehrt... :(

@p3x-robot danke für das Feedback. Falls Sie interessiert sind, habe ich ein Thema erstellt und werde mich

@nornagon, also können wir Electron 6 nicht einmal auf Debian ausführen und es gibt keine Möglichkeit, einem Chrome-Prozess Root-Perms zu erteilen. Die angegebenen Workarounds sind aus Benutzersicht nicht ausreichend.

Es gibt zwei Problemumgehungen:
Aktivieren Sie den unprivilegierten Zugriff auf CLONE_NEWUSER in Ihrem Kernel. Einige Kernel unterstützen die Änderung mit sysctl kernel.unprivileged_userns_clone=1.

Es gibt absolut keine Möglichkeit, sich mit dem Computer des Kunden zu befassen.

Deaktivieren Sie Sandboxing vollständig, indem Sie mit --no-sandbox starten. Dieses Argument von JS hinzuzufügen reicht leider nicht aus, da der GPU-Prozess gestartet wird, bevor der Hauptprozess JS ausgeführt wird.

Wie wäre es, wenn Sie ein --sandbox Flag hinzufügen und die Sandbox-Funktion standardmäßig deaktivieren? Dies hat den Vorteil, dass 99% der Leute, die Electron verwenden, nicht verarscht werden.

Die angegebenen Workarounds sind aus Benutzersicht nicht ausreichend.

Die Verwendung eines Loader-ähnlichen Skripts/Programms, das --no-sandbox arg hinzufügt, kann auch als Problemumgehung angesehen werden, sodass keine Endbenutzeraktionen erforderlich sind. Außerdem könnte ein solcher Loader zuerst die user namespace Unterstützung testen und --no-sandbox nur bei Bedarf hinzufügen.

@pronebird , die binäre setuid root von auszuführen . Bedenken Sie: _Sie sind_ derjenige, der die Electron-Binärdateien versendet, damit Sie sicher sein können, dass Sie vertrauenswürdigen Code versenden (zB indem Sie ihn unterschreiben). Wenn Ihre App jedoch davon überzeugt werden kann, nicht vertrauenswürdigen Code zu laden (möglicherweise absichtlich, z. B. durch Navigieren zu einer URL im Web), dann führt die App diesen Code mit Zustimmung des Benutzers ohne jede Art von Sandbox aus. Ich wäre viel mehr besorgt über die Abwehr von Angriffen, die darauf abzielen, nicht vertrauenswürdiges JS in einem nicht Sandbox-Prozess in Ihrer App auszuführen, als über Angriffe, bei denen ein Fehler in demselben Sandboxing-System ausgenutzt wird, das Chrome verwendet. (Und ich würde erwarten, dass letztere _sehr schnell_ behoben werden, wenn sie entdeckt werden.) Wenn Sie den Code der Binärdatei chrome-sandbox selbst prüfen möchten, können Sie hier beginnen: https://chromium.googlesource. com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424

Wenn Sie ohne eine Electron-Sandbox arbeiten möchten, würde ich dringend empfehlen, auf andere Weise Sandboxing durchzuführen, zB Snapcraft oder Flatpak, Paketprogramme, für die ich glaube, dass sie Launcher-Skripte enthalten, die die Sandbox von Electron im Container deaktivieren.

@nornagon

Das Geben der binären setuid-Stammdatei von chrome-sandbox ist viel weniger gefährlich, als Electron ohne eine Sandbox auszuführen. Bedenken Sie: Sie sind derjenige, der die Electron-Binärdateien versendet, also können Sie sicher sein, dass Sie vertrauenswürdigen Code versenden (zB indem Sie ihn unterschreiben). Wenn Ihre App jedoch davon überzeugt werden kann, nicht vertrauenswürdigen Code zu laden (möglicherweise absichtlich, z. B. durch Navigieren zu einer URL im Web), dann führt die App diesen Code mit Zustimmung des Benutzers ohne jede Art von Sandbox aus. Ich wäre viel mehr besorgt über die Abwehr von Angriffen, die darauf abzielen, nicht vertrauenswürdiges JS in einem nicht Sandbox-Prozess in Ihrer App auszuführen, als über Angriffe, bei denen ein Fehler in demselben Sandboxing-System ausgenutzt wird, das Chrome verwendet. (Und ich würde erwarten, dass letztere sehr schnell behoben werden, wenn sie entdeckt werden.)

Sicher, aber das Ausführen einer Sandbox macht wenig Sinn, wenn Sie eine App haben, die niemals Remote-Inhalte lädt. Ich glaube, das muss bei Electron der Fall sein – zum Erstellen von Desktop-Apps mit Webstack, zum Laden von vielleicht JSON aus dem Web, aber nicht nur zum Anzeigen von Webseiten, als hätten wir dafür Safari nicht. Wir sind vorbei an den Zeiten, in denen die Leute Websites in Telefonlücken hüllten, nicht wahr?

Ich finde den Overhead viel zu hoch. Ich habe heute ein Bootstrap-Skript zu unserer App hinzugefügt und die Binärdatei chrome-sandbox aus der Distribution entfernt, die weitere 5 MB betrug. Leider unterstützt electron-builder nichts davon, also mussten wir einen Hook hinzufügen und es selbst machen.

Wenn Sie den Code der chrome-sandbox-Binärdatei selbst prüfen möchten, können Sie hier beginnen: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. c#424

Danke. Es hängt wirklich von einem Bedrohungsmodell ab, und wir können auf keinen Fall etwas von Google mit Root-Berechtigungen ausführen.

Es kann völlig sicher sein, aber es wäre auch wirklich schwer zu überprüfen, ob alle Quellen intakt sind, da Elektronenaufbauten über npm versendet werden. Wir müssten einen benutzerdefinierten Build-Server für Electron einrichten und die Quellen selbst prüfen. Das wäre ein enormer Aufwand und ich würde ihn lieber vermeiden.

@pronebird Ich werde mich nicht zu sehr in die Sandbox-Diskussion

Es kann völlig sicher sein, aber es wäre auch wirklich schwer zu überprüfen, ob alle Quellen intakt sind, da Elektronenaufbauten über npm . versendet werden

Dies ist grundsätzlich falsch, Elektronen-Builds werden nicht über npm versendet. Das electron Paket auf npm besteht eigentlich aus 2 Dateien und ~40 Zeilen JS. Die tatsächlichen Electron-Builds werden über S3 geliefert und haben auch Prüfsummen auf S3, damit die Leute überprüfen können, ob der Build, den sie herunterladen, tatsächlich der von Electron gelieferte Build ist.

@MarshallOfSound

Dies ist grundsätzlich falsch, Elektronen-Builds werden nicht über npm versendet. Das Elektronenpaket auf npm besteht eigentlich aus 2 Dateien und ~40 Zeilen JS. Die tatsächlichen Electron-Builds werden über S3 geliefert und haben auch Prüfsummen auf S3, damit die Leute überprüfen können, ob der Build, den sie herunterladen, tatsächlich der von Electron gelieferte Build ist.

Was ich meinte, ist, dass die Builds während der npm install Phase heruntergeladen werden. Ich meinte nicht, dass sie physisch auf npm gehostet werden. Lassen Sie es sein, dass sie auf S3 gehostet werden. Beweisen Sie mir das Gegenteil, aber ich wette, dass Prüfsummen auf demselben S3 gehostet werden, was den Sicherheitsgrad eines solchen Systems verringert, es ist nur ein Bein. Aber das ist nicht der Punkt. Stellen Sie sich das Szenario vor, in dem Ihre Builds manipuliert und die Prüfsummen entsprechend aktualisiert werden. Jetzt haben wir ein Problem. Das ist einfach eine Risiko- und Schadensbegrenzung auf meiner Seite. Keine Wurzel = geringeres Risiko, dass etwas wirklich Schlimmes passiert.

@pronebird Chrome-Sandbox-Binärdatei sollte definitiv nicht 5 MB groß sein, das ist ein Fehler. Geöffnet #20049, um das Problem zu beheben, danke für den Hinweis.

Natürlich können Sie Sandboxing für Ihren Anwendungsfall deaktivieren. Es ist bedauerlich, dass die Architektur von Chromium es so macht, dass Sie --no-sandbox direkt auf der Befehlszeile übergeben müssen, anstatt app.commandLine.appendSwitch aufzurufen; Im Idealfall wäre das Deaktivieren der Sandbox möglich, ohne dass ein Wrapper-Skript erforderlich wäre. Hoffentlich wird mit #20049 die Sorge, die Binärdatei zu entfernen, gemildert, da 200 KB zusätzlich viel vernünftiger sind als 5 MB.

Gibt es eine Option für die Verwendung einer Systembinärdatei? Ich habe Vorbehalte, allem in meinem node_modules/-Ordner ein suid-root-Bit zu geben. Danke.

@gardner Sie könnten --no-sandbox arg übergeben, was eine einfache Problemumgehung ist, wenn Sie sich im Entwicklungsmodus befinden.

VSCode ist erst vor kurzem auf Electron 6 umgestiegen und jetzt erhalten wir Berichte, dass VSCode nicht mehr startet, es sei denn, die Option --no-sandbox wird bereitgestellt. Wie geht es hier weiter? Referenzen: https://github.com/microsoft/vscode/issues/81056

snap funktioniert jetzt out of the box, für appimage gibt es einen hart geschriebenen Code:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

den Rest weiß ich nicht, ich veröffentliche nur NPM, AppImage und SNAP...

im Grunde müssen Sie jeden Elementtyp neu packen, um dem Launcher-Skript ein Argument ( --no-sandbox ) hinzuzufügen.

Es gibt keine Lösung für Electron 6, denke ich, entweder Sie müssen es basierend auf Ihren Paketen schreiben oder auf einen Fix oder ein Downgrade warten ...

Für ein besseres Entwicklererlebnis. Wir können einen Befehl wie unten im Elektron-Cli-Tool einrichten.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Ein Befehl wie electron --ConfigSandbox.
Der Benutzer wird sich dessen bewusst und die Sandbox kann einfach konfiguriert werden.
Und das schon beim ersten Lauf. Wir können sie fragen, ob sie die Maßnahmen ergreifen möchten. j oder n. Und dann müssen sie nur noch das Passwort eingeben. So ist es auf einen Blick erledigt. Und es wird zu einer großen Benutzererfahrung führen und Zeit gewinnen. Denn du vertraust dem Anbieter oder der Community. Und geh damit. Anstatt im ganzen Netz zu suchen. Und das ist für die Anfänger von uns noch wertvoller. Und schön ist es auf alle Fälle.

Dieses Problem wurde geschlossen, aber ich habe es immer noch mit Electron 7.0.0. Gibt es einen Commit, der zu einem Fix geführt hat?

Warum wurde das Thema geschlossen? Es scheint kein Fix verfügbar zu sein, da er auch in v7.0.0 weiterhin besteht

Denn es geht um das Verpacken Ihrer App, aber nicht um Electron.

Ah, in Ordnung. Aber wie kann ich das beheben? Gibt es eine Möglichkeit, bei der der Endbenutzer keine zusätzliche Arbeit leisten muss?

Gibt es eine Möglichkeit, bei der der Endbenutzer keine zusätzliche Arbeit leisten muss?

Ja, es gibt einen Weg, der schon einmal diskutiert wurde.

sudo sysctl kernel.unprivileged_userns_clone=1

Es gibt ein Problem mit WSL-Benutzern (es gibt viele, die WSL verwenden) und WSL 1 verwendet keinen echten Linux-Kernel ... wir müssten auf die Veröffentlichung von WSL2 warten.

Als Referenz zu dieser Einschränkung: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS=y aktiviert die Funktion für Benutzernamensräume, aber sie sind standardmäßig immer noch auf privilegierte Benutzer beschränkt. Dies schlägt vor, sysctl kernel.unprivileged_userns_clone=1

Ich bestätige, dass die Ausführung von sudo sysctl kernel.unprivileged_userns_clone=1 eine weitere Problemumgehung ist, verwandter Kommentar .

Ja, ich benutze Manjaro und i3wm, ich habe den gleichen Fehler gemacht, aber damit funktioniert es.

Übersehe ich etwas oder ist es nicht mehr möglich, einfach eine Electron-App ohne Root-Zugriff herunterzuladen und auszuführen? Entschuldigung, ich hatte nicht bemerkt, dass dies spezifisch für Debian war und dass der Mainline-Kernel nicht einmal das Deaktivieren unprivilegierter Namespaces unterstützt.

Verzeihen Sie meine Kühnheit, aber das ist absolut verrückt. Electron macht die Node.js-API sogar in Renderer-Prozessen verfügbar. Die Verwendung/Aktivierung der Sandbox von Chromium in einer Electron-App ist völlig sinnlos, und wie Sie alle aus den Fehlerberichten rund um GitHub, die auf dieses Problem hinweisen, sehen können, ist dies auch höchst kontraproduktiv. Bitte deaktivieren Sie es wenn möglich.

Electron macht die Node.js-API sogar in Renderer-Prozessen verfügbar.

nodeIntegration Option

Entschuldigung, ich hatte nicht bemerkt, dass dies spezifisch für Debian war und dass der Mainline-Kernel nicht einmal das Deaktivieren unprivilegierter Namespaces unterstützt.

Wenn ich also Debian verwende, scheine ich Glück zu haben, dass ich Root-Zugriff auf meinem Computer habe. Aber liege ich richtig, dass diese Funktion Benutzer daran hindert, Elektronen-Apps (als AppImage oder nicht) ohne auszuführen?

a) sudo , oder
b) in der Lage sein, jemanden mit sudo davon zu überzeugen, nicht privilegierte Namespaces zu aktivieren?

@black-puppydog Nun, wenn sie die App aus dem Quellcode erstellen, könnten sie das Startskript bearbeiten, um das --no-sandbox Argument an Electron zu übergeben. Es sollte möglich sein, ein AppImage mit dem gleichen Effekt zu ändern (durch Auspacken und erneutes Packen), aber das habe ich selbst nicht versucht. Es ist auch nicht unmöglich, dass einige AppImage-Ersteller dieses Flag in ihre Builds aufnehmen, in diesem Fall würden diese spezifischen Bilder einfach funktionieren.

Ansonsten gebe ich dir recht. Beachten Sie, dass der Mainline-Kernel immer unprivilegierte Namespaces aktiviert hat und keine Möglichkeit bietet, diese zu deaktivieren. Daher ist dies nur ein Problem bei Debian.

@black-puppydog Soweit ich mich erinnere, fordert das Installationsprogramm Sie zur Eingabe eines Root-Passworts auf, wenn Sie Debian zum ersten Mal auf Ihrem Computer installieren. Aber ja, auf Debian (oder jedem anderen System, das den Kernel-Patch von Debian verwendet) müssen Sie entweder Root-Zugriff haben (über sudo oder anderweitig) oder Electron-Apps mit --no-sandbox ausführen.

@ndorf In Mainline-Linux können Benutzernamensräume deaktiviert werden, indem das Feature nicht kompiliert wird, aber sie können nicht zur Laufzeit aktiviert/deaktiviert oder nur auf privilegierte Prozesse beschränkt werden. Debian patcht seine Kernel so, dass Benutzernamensräume standardmäßig auf privilegierte Prozesse beschränkt sind, aber für alle Prozesse mit einer Einstellung unter /proc/sys aktiviert werden können.

Der Grund, warum Debian es einschränkt, ist, dass unprivilegierte Benutzernamensräume ein ernsthaftes Sicherheitsrisiko mit einer langen Geschichte von Schwachstellen darstellen. Unprivilegierte Benutzernamensräume ermöglichen unprivilegierten Prozessen den Zugriff auf viele Kernel-Funktionalitäten (UID 0, Capabilities, Mounten eines Dateisystems, Erstellen eines Geräte-Inode usw.), die lange Zeit nur auf privilegierte Prozesse beschränkt waren. Jeder Code - Kernel auf der Annahme verlassen , dass nicht privilegierte Prozesse werden nie diese Dinge tun können, ist anfällig jetzt , dass nicht privilegierte Prozesse plötzlich in der Lage sind , diese Dinge zu tun.

Gibt es in der Zwischenzeit eine mögliche Problemumgehung, bis jede Linux-Distribution diese Funktionen aktiviert?

Siehe die ursprüngliche Nachricht:

Wenn ich die Datei chown und chmod, funktioniert es einwandfrei

Siehe auch hier #16631 (Kommentar) Damit die Suid-Sandbox funktioniert, müssen Sie im Grunde die Binärdatei chrome-sandbox diese Weise optimieren:

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

Das Problem ist jedoch schwerwiegender, wenn Sie appimage/snap-Pakete ausführen. Ich habe noch keine anständige Problemumgehung für diese Fälle offenbart. Es funktioniert, wenn appimage mit --no-sandbox Argument ausgeführt wird, aber dies ist ein Hack.

Dies funktioniert, wenn ich die Anwendung aus dem entpackten Verzeichnis ausführe. Wie verpacke ich dieses Verzeichnis, nachdem ich die Berechtigungen von chrome-sandbox geändert habe?

@shrinidhi111 4755 kann im verpackten zB . Was den Root-Besitzer angeht, erhalten die zugehörigen Dateien normalerweise den Root-Besitzer, wenn das Paket aus dem Repository unter Linux installiert wird. Im Fall von AppImage build packe ich es neu und kodiere --no-sandbox arg im inneren AppRun-Skript, da der Electron-Builder dies noch nicht aus der Box macht. Das Snap-Paket wird vom Electron-Builder mit fest codierten --no-sandbox arg gebildet (ein zugehöriger Fix wurde vor ~6 Monaten hinzugefügt).

@shrinidhi111 4755 kann beim zB . Was den Root-Besitzer angeht, erhalten die zugehörigen Dateien normalerweise den Root-Besitzer, wenn das Paket aus dem Repository unter Linux installiert wird. Im Fall von AppImage build packe ich es neu und kodiere --no-sandbox arg im inneren AppRun-Skript, da der Electron-Builder dies noch nicht aus der Box macht. Das Snap-Paket wird vom Electron-Builder mit fest codierten --no-sandbox arg gebildet (ein zugehöriger Fix wurde vor ~6 Monaten hinzugefügt).

Das Erstellen einer Snap-Datei war eine ausgezeichnete Idee und hat mir eine Menge Arbeit erspart. Danke noch einmal!

wie ist das immer noch ungelöst

on snap ist behoben, ich habe meinen eigenen Build, der mit appimage funktioniert. der Rest ist ungeklärt.

Dieser Thread ist unglaublich lang und der Fehler tritt immer noch auf. Gibt es irgendwo eine Zusammenfassung der Situation? Vielleicht könnte eine solche Zusammenfassung aus dem Fehler verlinkt werden.

Es klingt so, als ob https://github.com/electron/electron/issues/17972#issuecomment -495767027 und ähnliche vorschlagen, dass es ausreicht, die Elektronenfunktion einfach und sicher nur auf Systemen mit Root-Zugriff zu haben. Vielleicht wäre es schön, wenn das System die falschen Berechtigungseinstellungen erkennt und den Entwicklern Warnungen anbietet, um Benutzer zu reduzieren, die auf dieses Problem stoßen, aber vielleicht ist das ein separates Problem. Es scheint auch schön zu sein, wenn es einen Weg für Benutzer ohne Root-Zugriff gäbe, um Electron einfach zu verwenden, mit dem prominenten Verständnis, dass nicht vertrauenswürdige Ressourcen gefährlicher als üblich sind.

Pfad für Benutzer ohne Root-Zugriff, um Electron einfach zu verwenden

--no-sandbox CLI-Argument.

vladimiry, ich dachte z. B. an Endbenutzer ohne viel Terminal-Erfahrung oder das Ausführen von Apps, die Elektron umhüllen

Ich dachte z. B. an Endbenutzer ohne viel Terminalerfahrung oder das Ausführen von Apps, die Elektron umhüllen

Betten Sie --no-sandbox in die App-Verknüpfung ein. Jedes Linux-Paket hier wird unabhängig vom Systemwert von kernel.unprivileged_userns_clone funktionieren. Es geht also darum, die Bewerbung zu verpacken.

Das ist richtig, wenn ich Entwickler bin und meine Endbenutzer entsprechend warnen möchte. Werden viele Entwickler nicht von diesem Problem erfahren, weil die Namespace-Sandbox für sie funktioniert? Es ist auch besorgniserregend, dass vorhandene Lösungen vorhanden sind, ohne dass den beteiligten Personen mitgeteilt wird, dass nicht vertrauenswürdige Ressourcen gefährlicher sind.

Diese Lösung funktioniert nur, wenn Sie diesen Fehler aufgrund von WSL erhalten

Ich bin auf dieses Problem gestoßen, als ich versuchte, electron für WSL (WSL2 in meinem Fall) zu verwenden.
Electron konnte selbst bei Verwendung eines X11-Servers nicht über X11 laufen.

Ich musste Electron für Windows erstellen, auch wenn ich es in WSL ausführe. Danach funktioniert alles wie ausgenommen
Der einfachste Weg, dies zu tun:

• Elektron deinstallieren npm uninstall electron
• Npm-Konfigurationsplattform ändern export npm_config_platform=win32
• Elektron installieren npm install electron
• Deaktiviere die Umgebungsvariable unset npm_config_platform

Dies schlägt vor, sysctl kernel.unprivileged_userns_clone=1

Ich sehe dieses Problem mit WSL (Windows 10), Ubuntu 18.04, das in WSL installiert ist.
sudo sysctl kernel.unprivileged_userns_clone=1 funktioniert nicht.

sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

Die Verwendung von chown und chmod ist ebenfalls keine Option.

@MarshallOfSound zip unterstützt keine Berechtigungen, aber letztendlich ist das Problem nicht die chmod-Berechtigung, sondern der Besitzer. Der setuid-Sandbox-Helper ist suid _to root_, da er Funktionen ausführen muss, die nur root zur Verfügung stehen. Wenn es möglich wäre, die entsprechenden Berechtigungen zu setzen, ohne zuvor Root-Rechte zu erlangen, wäre das eine sehr gravierende Schwachstelle in Linux. Zum Glück für Linux und leider für uns ist das nicht der Fall.

zip _unterstützt_ Berechtigungen auf Unix-basierten Systemen (oder zumindest auf den von mir getesteten Linux-Varianten). Siehe https://serverfault.com/a/585889/17620

Die Berechtigungsbits werden im Dateiheader-Suffix des zentralen Verzeichnisses der ZIP-Datei gespeichert. Das externalFileAttributes Feld des Suffixes kann verwendet werden, um die Berechtigungsbits für jeden Datei-/Verzeichniseintrag zu speichern.

cc @MarshallOfSound

Ich habe das gleiche Problem !

[gxz<strong i="6">@localhost</strong> build]$ ./Electron-0.1.1.AppImage 
[23154:0521/155029.728314:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount-E0wZecV/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap(吐核)
[gxz<strong i="7">@localhost</strong> build]$ sudo ./Electron-0.1.1.AppImage 
[sudo] gxz 的密码：
[23191:0521/155048.067790:FATAL:electron_main_delegate.cc(211)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Trace/breakpoint trap
[gxz<strong i="8">@localhost</strong> build]$ 

Als normaler Benutzer ausführen , hat Fehler: FATAL:setuid_sandbox_host.cc(157)] 。Run as root , hat Fehler: FATAL:electron_main_delegate.cc(211)]

aber wenn ich Snap danach installiere, als Root oder normaler Benutzer ausführen, ist in Ordnung.

sudo chown root chrome-sandbox
sudo chmod 4755 chrome-sandbox

Das funktioniert gut.

@cuixiping es funktioniert :+1:

Ich tat

$ find . -name chrome-sandbox
./node_modules/electron/dist/chrome-sandbox

$ sudo chown root ./node_modules/electron/dist/chrome-sandbox

$ sudo chmod 4755 ./node_modules/electron/dist/chrome-sandbox

Ich hatte das gleiche Problem, als ich Electron auf Deepin ausgeführt habe, und ich habe das Problem mit diesem Code gelöst
electron . --no-sandbox

hoffe das hilft dir

funktioniert nicht

@fabiospampinato Ihre Anpassung deaktiviert die Sandbox für alle Linux-Pakettypen, aber zumindest DEB- und Pacman-Pakete funktionieren gut mit SUID-Sandbox (wahrscheinlich alle nicht containerähnlichen Pakete), es muss nur das SUID-Berechtigungsbit auf chrome-sandbox binär. Setzen Sie jedoch kein SUID-Berechtigungsbit für das Snap-Paket, da Snap Store solche Arten von Paketen ablehnt. Also setze ich das SUID-Bit für alle Linux-Pakete, die Snap/AppImage-Pakete erwarten, die Sandboxing deaktivieren, verwandter Code .

Hallo @vladimiry
Ich konnte nicht auf den Link zugreifen, den Sie hier angehängt haben. Können Sie dabei helfen?
Konnten Sie außerdem herausfinden, wie man --no-sandbox im Electron-Builder-After-Pack-Skript macht?

Danke

@tushar-compro, hier ist es https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Grundsätzlich setze ich 4755 Bit im After-Pack-Skript für einige Pakettypen und packe immer noch die appimage+snap-Pakete neu. Tatsächlich haben die Electron-Builder --no-sandbox arg bereits in Snap eingebettet, aber noch nicht in Appimage https://github.com/electron-userland/electron-builder/pull/4496. Übrigens, Electron-Builder setzt heutzutage schon 4755 Bit https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl #L7. Die neueste Version des Elektron-Builders sollte die Dinge für die meisten Entwickler vereinfachen.

@vladimiry
Bin ich richtig zu verstehen , dass Sie die 4755 - Bit für andere Ziele
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Das Problem tritt jedoch bei der Verwendung des .appimage-Installationsprogramms auf der Debian-Distribution auf.

Übersehe ich hier etwas?

Das Problem tritt jedoch bei der Verwendung des .appimage-Installationsprogramms auf der Debian-Distribution auf.

Wie gesagt bedarf das Appimage noch einer Sonderbehandlung. Ich packe es neu und bette das --no-sandbox in das ./AppRun Skript ein. Suchen Sie das Schlüsselwort DISABLE_SANDBOX_ARGS_LINE hier https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Das Problem tritt jedoch bei der Verwendung des .appimage-Installationsprogramms auf der Debian-Distribution auf.

Wie gesagt bedarf das Appimage noch einer Sonderbehandlung. Ich packe es neu und bette das --no-sandbox in das ./AppRun Skript ein. Suchen Sie das Schlüsselwort DISABLE_SANDBOX_ARGS_LINE hier https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Der neueste Electron Builder kümmert sich sowohl in snap als auch in appimage automatisch um das Argument no sanbox.

@vladimiry
Verstehe ich also richtig, dass die 4755-Bit-Einstellung, die Sie vorgenommen haben, für andere Installer als appimage und snap gilt. Und für appimage haben Sie keine Sandbox eingestellt. Kannst du bitte bestätigen.

@p3x-Roboter
ja. du hast teilweise recht.

1. Neuester Electron-Builder setzt keine Sandbox für Snap, aber NICHT für Appimage. Sie haben jedoch 4755 Bit für Appimage eingestellt.
2. In meinem Projekt verwende ich die Electron-Version 20.xx Das Aktualisieren auf 22.xx wird eine Anstrengung für sich sein. Versuche nur, das wenn möglich zu vermeiden. Ein Update auf v22 ist der letzte Ausweg.

Der neueste Electron Builder kümmert sich sowohl in snap als auch in appimage automatisch um das Argument no sanbox.

Das Appimage-spezifische Snippet, das dem für Snaps verwendeten ähnelt, konnte noch nicht in ihrem Code gefunden werden (https://github.com/electron-userland/electron-builder/pull/4496 noch geöffnet). Wie auch immer, in meinem Fall ist das Umpacken immer noch erforderlich, da ich dort zusätzliche Argumente hinzugefügt habe, die nicht sanbox-bezogen sind.

Verstehe ich also richtig, dass die 4755-Bit-Einstellung, die Sie vorgenommen haben, für andere Installer als appimage und snap gilt. Und für appimage haben Sie keine Sandbox eingestellt. Kannst du bitte bestätigen.

Richtig. Aber moderne Elektronen-Builder-Sets 4755 intern. Ich überprüfe jedoch, dass es nicht auf Snap/Appimage eingestellt ist, da dies ein Fehler wäre. Zum Beispiel startet Snap nicht mit 4755 Bit, das auf Elektron-Binär gesetzt ist, wenn ich mich richtig erinnere.

@vladimiry
Ich muss nur no-sandbox einstellen, da meine Appimages in Debian nicht funktionieren.

Ich glaube, ich brauche in diesem Fall kein Umpacken. Aber ich konnte nicht die richtige Dokumentation von Electron Builder dafür finden. Oder meinst du, ich muss auch umpacken?

Können Sie mir die richtige Dokumentation zeigen, die mir dabei helfen kann.

Außerdem verstehe ich, dass ich beide Optionen habe, entweder 4755 Bit oder keine Sandbox einzustellen.
Welche ist Ihrer Meinung nach besser?

Außerdem verstehe ich, dass ich beide Optionen habe, entweder 4755 Bit oder keine Sandbox einzustellen.

Wenn ich mich richtig erinnere, lösen die Einstellungen 4755 auf appimage das Problem nicht. Sie müssen (eines von):

• starte deine appimage-Datei mit --no-sandbox Kommandozeilen-Argument
• --no-sandbox in das ./AppRun Skript eingebettet haben, das sich in Ihrer Appimage-Datei befindet (daher ist ein Umpacken erforderlich).

Können Sie mir die richtige Dokumentation zeigen, die mir dabei helfen kann.

Ich bezweifle, dass Sie in einer Dokumentation detaillierte Informationen zu diesem Thema finden werden. Mir sind keine entsprechenden Dokumente bekannt.

Außerdem verstehe ich, dass ich beide Optionen habe, entweder 4755 Bit oder keine Sandbox einzustellen.

Wenn ich mich richtig erinnere, lösen die Einstellungen 4755 auf appimage das Problem nicht. Sie müssen (eines von):

• starte es mit --no-sandbox Kommandozeilen-Argument
• --no-sandbox in das ./AppRun Skript eingebettet haben, das sich in Ihrer Appiamge-Datei befindet (daher ist ein Umpacken erforderlich).

Können Sie mir die richtige Dokumentation zeigen, die mir dabei helfen kann.

Ich bezweifle, dass Sie in einer Dokumentation detaillierte Informationen zu diesem Thema finden werden. Mir sind keine entsprechenden Dokumente bekannt.

Der neueste Electron Builder bettet das --no-sandbox in das ./AppRun , das ich früher neu gepackt habe, aber jetzt ist es nutzlos, ich benutze nur den nativen Electron Builder.

@vladimiry
ja. Die Einstellung von 4755 allein funktioniert nicht. Bei 4755 müssen wir den Besitzer von chrome-sandbox auf root ändern.
Auf jeden Fall vielen Dank für deine Hilfe. Ich werde versuchen, auf Ihren Code zu verweisen und die Sandbox dann einzustellen.

@p3x-Roboter
Können Sie bitte einen Link (Elektronen-Builder-Repo) teilen, in dem wir den Code sehen können, der dies tut.

https://github.com/patrikx3/onenote

@vladimiry
ja. Die Einstellung von 4755 allein funktioniert nicht. Bei 4755 müssen wir den Besitzer von chrome-sandbox auf root ändern.
Auf jeden Fall vielen Dank für deine Hilfe. Ich werde versuchen, auf Ihren Code zu verweisen und die Sandbox dann einzustellen.

@p3x-Roboter
Können Sie bitte einen Link (Elektronen-Builder-Repo) teilen, in dem wir den Code sehen können, der dies tut.

https://github.com/patrikx3/onenote

Electron Builder bettet zuletzt die --no-sandbox in ./AppRun ein, die ich früher neu gepackt habe, aber jetzt ist es nutzlos, ich verwende einfach den nativen Electron Builder.

Ich habe es gerade mit der neuesten Electron Builder-Version getestet und es bettet die --no-sandbox nicht in das ./AppRun-sh-Skript ein. Wenn Sie das Appimage starten, schlägt es mit einem bekannten [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found ähnlichen Fehler fehl. Vielleicht haben Sie das kernel.unprivileged_userns_clone Flag auf Ihrem System aktiviert. Wenn ja, versuchen Sie, es wie sudo sysctl kernel.unprivileged_userns_clone=0 deaktivieren und die Appimage-Datei erneut zu starten.

Electron Builder bettet zuletzt die --no-sandbox in ./AppRun ein, die ich früher neu gepackt habe, aber jetzt ist es nutzlos, ich verwende einfach den nativen Electron Builder.

Ich habe es gerade mit der neuesten Electron Builder-Version getestet und es bettet die --no-sandbox nicht in das ./AppRun-sh-Skript ein. Wenn Sie das Appimage starten, schlägt es mit einem bekannten [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found ähnlichen Fehler fehl. Vielleicht haben Sie das kernel.unprivileged_userns_clone Flag auf Ihrem System aktiviert. Wenn ja, versuchen Sie, es wie sudo sysctl kernel.unprivileged_userns_clone=0 deaktivieren und die Appimage-Datei erneut zu starten.

komisch, es gibt 10.000 Snap-Installationen mit dem neuesten Electron Builder. und definitiv zeigt der Electron Builder, dass er dieses Flag hinzufügt ...

es gibt 10k snap

Wir sprechen über Appimage, nicht über das Snap-Ding. Snap hat natürlich das Argument eingebettet, wie ich oben erwähnt habe, hier https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

es gibt 10k snap

Wir sprechen über Appimage, nicht über das Snap-Ding. Snap hat natürlich das Argument eingebettet, wie ich oben erwähnt habe, hier https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

Sie haben Recht. Ich dachte aus irgendeinem Grund, dass es in Appimage gemacht wurde, ich habe sogar den Code für das Neupaket entfernt und keine Sandbox hinzugefügt, aber ich habe es erneut versucht und sehe, dass es fehlt, also habe ich mein Zurücksetzen meines Builds hinzugefügt, nein es funktioniert. sorry, in meinem corifeus-builder kannst du sehen was ich mache: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Hallo @nornagon Wenn man bedenkt, wie häufig dieses Problem Schnellstart- Tutorial für Elektron aktualisiert werden, um die Problemumgehung aufzunehmen, damit Neulinge eine positive Erfahrung machen?

Bearbeiten: Dank der Ermutigung der Community habe ich eine FR #26478 geöffnet

@gabefair Das scheint ein vernünftiger Vorschlag zu sein. Haben Sie Interesse, eine PR zu eröffnen?