运行node_modules/.bin/electron --version
应该输出v5.0.0
。
需要明确的是,所有命令都会创建此错误,但为了简单起见,我使用了--version
标志。
$ node_modules/.bin/electron --version
[2720:0425/142001.775056: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 /home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.
$ stat /home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/chrome-sandbox
Size: 5185424 Blocks: 10128 IO Block: 4096 regular file
Device: 802h/2050d Inode: 1465270 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/christianbundy) Gid: ( 1000/christianbundy)
Access: 2019-04-25 14:15:10.609279524 -0700
Modify: 2019-04-25 14:15:10.659278929 -0700
Change: 2019-04-25 14:15:10.659278929 -0700
Birth: 2019-04-25 14:15:10.609279524 -0700
如果我chown
和chmod
文件那么它工作正常,但我的直觉是npm install electron@latest
应该在没有这些命令的情况下工作。 这是预期的行为吗?
不幸的是,我们无法自动正确配置它,因为设置适当的权限需要 root 权限,而且我们不想在npm install
期间要求提供 root 密码。
理想情况下,Arch 将配置其内核支持非特权 CLONE_NEWUSER 并且 Chromium(和 Electron)可以使用命名空间沙箱而不是依赖旧的 setuid 沙箱。 在 Linux 上分发的应用程序需要将其合并到他们的安装过程中。 例如,参见https://github.com/electron-userland/electron-installer-debian/pull/184和https://github.com/electron-userland/electron-installer-redhat/pull/112 。
在开发过程中,如果我们检测到命名空间沙箱不可用,我们可能应该在npm install
上打印一些内容,但带有说明。
嘿,感谢您的超级快速响应!
非特权 CLONE_NEWUSER 是否来自CONFIG_USER_NS=y
? 如果是这样,那应该是当前配置。
请让我知道是否有什么我可以帮忙的,或者如果这是 Arch 上的预期输出,我很乐意关闭——我知道在运行最前沿的发行版时会出现一些问题,我不介意在PKGBUILD
解决这个问题,而不是期望它直接从 npm 中完美运行。 干杯!
CONFIG_USER_NS=y
启用用户命名空间功能,但默认情况下它们仍然仅限于特权用户。 这表明sysctl kernel.unprivileged_userns_clone=1
在每个 linux 发行版都启用这些功能之前,是否有可能的解决方法?
@kitingChris setuid 沙箱是解决方法。 您只需要确保在开发/发布电子应用程序时,您的开发/打包脚本将沙箱助手的权限正确设置为上面链接的
在每个 linux 发行版都启用这些功能之前,是否有可能的解决方法?
看原文:
如果我 chown 和 chmod 文件然后它工作正常
另请参见此处https://github.com/electron/electron/issues/16631#issuecomment -476082063 因此,要使 suid 沙箱工作,您基本上必须以这种方式调整chrome-sandbox
二进制文件:
sudo chown root chrome-sandbox
chmod 4755 chrome-sandbox
这个问题更严重,但如果运行 appimage/snap 包,我还没有为这些情况透露一个像样的解决方法。 如果 appimage 使用--no-sandbox
argumentmnt 执行,它就可以工作,但这是一个 hack。
@nornagon
因为设置适当的权限需要 root 权限,我们不想在 npm install 期间要求 root 密码。
执行chmod 4755 node_modules/electron/dist/chrome-sandbox
不需要 root 权限,这应该足以运行这样的命令来将应用程序包装到 deb/pacman/etc 包,因为当这些包被安装时,包括chrome-sandbox
在内的所有文件正常归根拥有。 因此,电子在安装过程中自动执行chmod 4755 node_modules/electron/dist/chrome-sandbox
会很棒,因为这样就不需要像这里提到的那样手动处理这种情况。
CONFIG_USER_NS=y 启用用户命名空间功能,但默认情况下它们仍然仅限于特权用户。 这表明 sysctl kernel.unprivileged_userns_clone=1
我确认执行sudo sysctl kernel.unprivileged_userns_clone=1
是另一种解决方法,相关评论。
@vladimiry我需要先 chown 然后 chmod。 反过来,它不起作用。
@burningTyger你是对的,我只是改变了原始信息。
@nornagon如果我们在 CI 上chmod 4755 out/Release/chrome-sandbox
将在我们zip
后保留该权限,还是必须在electron-download
进行此更改以修复对 DL 的权限?
同样,对于需要改变的东西来说,这是一个糟糕的新功能...... :(
@MarshallOfSound zip 不支持权限,但最终问题不是 chmod 权限,而是所有者。 setuid 沙箱助手是 suid _to root_,因为它需要执行只有 root 才能使用的功能。 如果不先获得root权限就可以设置适当的权限,那将是Linux中一个非常严重的漏洞。 对 Linux 来说幸运的是,对我们来说不幸的是,情况并非如此。
以下是我看到的选项:
我倾向于(2)。 它将在不损害已部署应用程序的安全性的情况下简化开发。
我还不确定如何处理 snap/flatpak,因为我不熟悉它们的工作原理。 可能他们已经对应用程序进行了充分的沙箱处理,我们可以在这种情况下完全禁用沙箱,就像我们在构建 Mac App Store 版本的 Electron 时所做的那样。
至于现在,我更喜欢第一个选项。
- 如果仅在启动未打包的应用程序时没有可用的沙盒方法,则无需沙盒启动。 如果 Electron 正在启动打包的应用程序,请拒绝在没有沙箱的情况下启动。
这种情况会以某种方式误导。 一个人可能会在没有沙箱的情况下成功运行未打包的应用程序,但是打包的应用程序可能无法在启用沙箱的情况下以相同的方式运行。 例如,当您从渲染器进程而不是通过remote
接口访问主进程时的情况。 或者将应用程序包装到 AppImage / Snap / Flatpak 包的情况。
- 在所有情况下,如果没有可用的沙盒方法,则在不使用沙盒的情况下启动并打印警告。
因此,如果没有可用的沙箱,则设计和开发为沙箱的打包应用程序可能会在没有沙箱的情况下执行。 这对我来说听起来不太好。
- 在 Linux 上默认禁用沙箱。
这究竟是什么意思? 如果没有可用的沙箱(当前情况,强制沙箱),在 Linux 上启用沙箱的方式是应用程序启动或失败的方式。
我也喜欢 (1),但为了捍卫 (2),在禁用沙箱时,暴露给应用程序的 API 不会改变。 我们唯一要禁用的是操作系统级别的沙箱。 我们仍然会以相同的方式加载应用程序,只是它不会受到操作系统的保护。
我们仍然会以相同的方式加载应用程序,只是它不会受到操作系统的保护。
然后对我来说也很好听。 感谢您的解释。
我不喜欢 2.,因为可选的安全性通常会导致人们禁用安全性。
现在步入“愚蠢的用户”的境地,我宁愿看到 Electron 默认工作。 如果这是一项非常重要的安全措施,请给我一个警告并详细解释为什么我需要做额外的工作。 如果它不是那么重要,那么不要给我不好的“它不起作用”的味道。
正因为如此,我喜欢 1.(强行退出,就像现在一样)或 4。
:x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox
给我带来了一些危险信号。
只是要非常清楚它的作用:它在chrome-sandbox
上设置 SUID 位,这使得 _any user_ 能够以 root_ 身份执行文件。 这意味着如果有任何方式恶意使用chrome-sandbox
,或者如果内容被恶意使用,任何用户都可能成为 root。 chrome-sandbox
将是一个非常有趣的攻击目标。
我强烈建议不要在npm install
上执行此解决方法,因为它需要sudo
(用户需要写密码),这是侵入性的,我们可能不了解这样做的安全后果。
chown root:root chrome-sandbox && chmod 4755 chrome-sandbox 为我提出了一些危险信号。
当然,确实如此。 但是您可以启用用户命名空间沙箱作为替代sudo sysctl kernel.unprivileged_userns_clone=1
(默认情况下在 Ubuntu 上启用,但在 Arch 上不启用)。
只是要非常清楚它的作用:它在
chrome-sandbox
上设置 SUID 位,这使得 _any user_ 能够以 root_ 身份执行文件。 这意味着如果有任何方式恶意使用chrome-sandbox
,或者如果内容被恶意使用,任何用户都可能成为 root。chrome-sandbox
将是一个非常有趣的攻击目标。
是的,而且这个二进制文件与 Chrome 附带的二进制文件完全相同,所以如果您担心这一点,您可能还应该卸载 Chrome :)
有没有办法在没有沙箱的情况下运行/在没有“沙箱助手”的情况下运行? 收到第一批用户投诉😅
我希望这会禁用沙箱,但仍然会收到The SUID sandbox helper binary was found, but is not configured correctly
错误。
我不想回滚到电子 4.x 🤨
我尝试在chrome-sandbox
上上传带有 suid 标志的快照,但是 snapcraft 的审核过程禁止使用 suid 标志。
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'
如果 Snapcraft 禁止 suid 标志,那么可能唯一的选择是在 Snapcraft 中完全禁用 Electron 的沙箱并依赖于 Snapcraft 使用的容器。 我不确定最好的方法是什么——在通过 Snapcraft 打包时是否可以指定额外的命令行标志? 如果是这样,我们可以添加--no-sandbox
标志。 如果没有,我们可能需要添加一些特定的检测机制来检测在 Snapcraft/Flatpak 中运行并基于该检测禁用沙箱。
@posix4e您能否说明在用户命名空间和 SUID 沙盒/回退模式下运行沙盒 Snap 包的问题? 看起来您已经获得了调整 Brave 浏览器的 snap 配置的相关经验。 抄送@flexiondotorg。
只是要非常清楚它的作用:它在
chrome-sandbox
上设置 SUID 位,这使得 _any user_ 能够以 root_ 身份执行文件。 这意味着如果有任何方式恶意使用chrome-sandbox
,或者如果内容被恶意使用,任何用户都可能成为 root。chrome-sandbox
将是一个非常有趣的攻击目标。是的,而且这个二进制文件与 Chrome 附带的二进制文件完全相同,所以如果您担心这一点,您可能还应该卸载 Chrome :)
我有点担心让 Chrome 的二进制文件设置root:root
并设置 SUID,是的。 很少有代码没有错误。 这里是源代码,备案: https :
但我更担心npm install
是否会:
root:root
和 SUID 文件之一。我认为这将是我所知道的第一个软件堆栈,它会自动对非 root 用户拥有的文件执行sudo chown root:root && sudo chmod 4755
。
在 npm install 上执行sudo chown root:root && sudo chmod 475
应该是不可能的,npm 需要以 root 身份运行才能设置权限。 npm 的钩子模型将允许所有已安装的包也以 root 身份运行它们的钩子。 可能有数百个包和嵌套的依赖项,这将是非常危险的。
在 npm install 上执行 sudo chown root:root && sudo chmod 475 应该是不可能的
据我所知,这不被视为一种选择。
我同意在 npm install 期间做任何需要 root 权限的事情都是不可能的。 这就是为什么我没有将其列为选项之一。
就其价值而言, electron-installer-debian
1.2.0、 electron-installer-redhat
1.1.0 和electron-installer-snap
3.2.0 已随 SUID 沙箱更改一起发布。 Electron Forge v5 和 v6 beta 也应该传递更新(通过范围内的版本更新,适当地使用npm update
或yarn upgrade
)。
为了清楚起见,只需链接相关代码。
需要明确的是,对于 Snaps,还有更多功能(即,如上所述添加浏览器沙箱支持)。 有关详细信息,请参阅相关 PR 的更改。
我刚刚点击了这个,chown / chmod 可以工作,但是如果您在 Docker 映像中运行,这并不是唯一需要采取的措施。
如果你只是这样做,你会收到另一个错误:
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
解决方法是将--privileged
到docker run
命令中。 我认为这不是一个好的解决方案,主要是在 CI 上。
@JCMais听起来 Electron 错误地尝试使用--disable-namespace-sandbox
强制使用 suid 沙箱。 如果您使用--privileged
(或--cap-add SYS_ADMIN
或允许 CLONE_NEWUSER 的自定义 seccomp 配置文件)启动 docker,则沙箱内将提供命名空间,并且不需要 setuid 沙箱或其辅助可执行文件.
像@thomasnordquist一样,我现在使用预加载脚本禁用了 Snap/AppImage 包的沙箱。 您创建名为原始二进制文件的类似预加载的 sh 脚本,然后用于加载带有--no-sandbox
参数的重命名/原始电子二进制文件。 在electron-builder的after-pack
脚本中很方便
@nornagon我到底应该如何将这个标志传递给电子? 我尝试只添加--disable-namespace-sandbox
但它一直给我一个错误:
:~$ electron --disable-namespace-sandbox
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
可以确认这让我瞬间崩溃,我们所有的 Linux 用户都被困在旧版本上,直到我能解决这个问题。
我完全赞成一种提高安全性的方法,但在发货时没有将其关闭的功能标志。
我还想争辩说,如果没有通过代码禁用它的功能,就不应该发布它。 我想这可能是偶然的,因为 --no-sandbox 除非从命令行手动给出,否则不起作用。
如果electron-installer-snap
实现沙箱支持的方式有问题,请在其问题跟踪器中告诉我。
如果电子安装程序快照实现沙箱支持的方式有问题,请在其问题跟踪器中告诉我。
我还想听到有人确认更改足以解决 Snap 包的问题。 因此,欢迎正面/负面反馈。 查看相关信息。
@vladimiry我继续进行测试,但没有奏效。
我需要一个不能解决操作系统补丁、sysctl 或重启问题的解决方案。 我需要一些现在有效的东西。 --no-sandbox 将是首选。
如果有人可以提供一个最小的 Electron 应用程序,我可以用它来重现无功能的打包 Snap,那对我来说会更有帮助。 我使用electron-quick-start
的叉子在 CircleCI 中构建了一个 Snap 并将其安装在我的(Debian Stretch)笔记本电脑上,以验证我的更改至少构建了一个正常运行的 Electron 应用程序。
“不起作用”并不能帮助我确定我可以在electron-installer-snap
做什么才能为其他人正确打包。
@burtonator ,感谢您测试这些东西。 据我所知,打包到 Snap/AppImage 构建加载程序类似 bash/sh 脚本中,该脚本使用--no-sandbox
cmd 参数启动原始二进制/电子是目前唯一经过验证的解决方法。
@malept在测试这些东西之前,需要通过执行sudo sysctl kernel.unprivileged_userns_clone=0
来禁用用户命名空间操作系统功能。
@vladimiry是的,我的笔记本电脑已经有了那个用户设置。
CONFIG_USER_NS=y 启用用户命名空间功能,但默认情况下它们仍然仅限于特权用户。 这表明 sysctl kernel.unprivileged_userns_clone=1
我确认执行
sudo sysctl kernel.unprivileged_userns_clone=1
是另一种解决方法,相关评论。
谢谢伙计,为我工作! @弗拉迪米里
你们知道它现在是否适用于 5.0.2 吗?
@p3x-robot 在变更日志中没有提到这个问题。 刚刚检查确定,错误仍然存在。
@rybaczewa感谢您的回复,我也继续使用 v4,因为这是一个大问题,等不及 v5 运行了,ciao
不能等到 v5 工作
v5 正在运行
为了让这个线程中的人清楚@p3x-robot @rybaczewa这个问题是开放的,用于信息/下游目的。 Electron 本身按预期工作,我们没有什么可以“修复”的。
如果您看到此日志消息,则需要运行sudo sysctl kernel.unprivileged_userns_clone=1
或为chrome_sandbox
二进制文件提供错误消息中概述的正确权限。
@vladimiry @MarshallOfSound你为什么说这是固定的? 在 Snap 中,我无法安装我的应用程序 P3X Redis 和 P3X Onenote,既没有sudo sysctl kernel.unprivileged_userns_clone=1
也没有提供chrome_sandbox
v5.0.x。 我只能用 v4.xx 安装
您认为用户会想要使用sudo
吗? 他们会认为这个程序很糟糕,他们会卸载该应用程序。
v5 版本或 v6 或 v7 无法正常工作,因此这是一个错误:
上面提到的@p3x-robot snap
支持取决于您如何捕捉。 electron-installer-snap
支持开箱即用,如上所述,如果该模块有问题/不工作,请在该模块上提出问题。
有关详细信息,请参阅electron-installer-snap
库或浏览器沙盒中的snapcraft 文档
重申一下,我目前的理解是没有需要修复的错误,Electron 的沙箱正在按预期运行。 这里讨论的是人们在打包chrome_sandbox
二进制文件时面临的问题
这很奇怪,因为我已经添加了沙箱:
app.enableSandbox()
app.commandLine.appendSwitch('no-sandbox')
输出:
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$
我试试这个: app.enableSandbox()
,但我得到:
Uncaught ReferenceError: require is not defined
at onload.js:1
如果我删除该行,它会起作用。
@MarshallOfSound我正在使用electron-builder
对于你们所有人,如果你想让它工作,我创建了一个助手:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
如果你使用electron-builder
,你可以这样添加:
对于你们所有人,如果你想让它工作,我创建了一个助手:
这个问题讨论中已经多次提到这样的解决方案,这就是为什么我之前写过electron v5正在工作。
@vladimiry谢谢,我错过了这个解决方案,我只是添加了一个 javascript 本机解决方案而不是打字稿...
唯一的问题是,当我在打包 hack 之后,它没有在面板上使用来自电子的图标,但它会生成第二个图标,你们如何解决? 我认为这是无沙箱标志。 任何人?
它只发生在--no-sandbox
:
@p3x-robot 有一种方法可以将--no-sandbox
参数添加到打包到 Snap 容器应用程序中,而无需引入类似预加载器的 bash/sh 脚本:
unsquashfs your-snap-file.snap
解压 snap。./squashfs-root/command.sh
。snapcraft pack ./squashfs-root
命令将./squashfs-root
文件夹打包回 snap 包。我没有尝试,但我认为类似的重新打包操作也可以应用于 AppImage 包,即执行不同的解包/打包命令的问题。
我猜所描述的重新打包操作可以在afterAllArtifactBuild
电子构建器的钩子中触发。
@vladimiry ,非常感谢,因为 afterAllArtifactBuild 很有趣,我将尝试在不解包的情况下更改 command.sh,但它是明天的,再次感谢!
一个对 afterAllArtifactBuild 很有趣
@p3x-robot afterAllArtifactBuild
钩子实际上没有像我预期的那样被触发,但是很容易以编程方式触发 Snap 或任何其他包类型的构建。 请参阅此处的代码示例。 snapFile
是这里的结果文件,因此您可以解压/ unsquashfs
然后应用所需的更改并打包/ snapcraft pack
。 在示例代码中,我将 Hunspell 词典打包到 Snap 的./usr/share/hunspell
文件夹中。
@vladimiry我只使用 Electron v4,因为它正在工作。 我想有人会解决这个问题。
@p3x-robot 我仍然倾向于认为您必须承认没有什么可以解决的。
@vladimiry 当然没有什么可以解决的。 :)
有人知道 Electron v5.0.2 是否可以处理沙箱问题?
它与 v.5.0.0 相同 :smile:
我希望这不是题外话,但对于 Debian (9) 上的 AppImages,我收到错误消息:
The setuid sandbox is not running as root.
如果我错了,请纠正我,但我明白(主要来自本次讨论)这是由禁用的用户命名空间功能引起的,该功能在 Debian 上默认禁用。
所以关于这个建议:
- 在 Electron 中什么都不改变。 建议开发人员在其内核上启用非特权 CLONE_USERNS 以允许运行命名空间沙箱而不是 setuid 沙箱。
我想向用户显示一条消息,说它仅在启用用户命名空间功能时才有效(可能会提示如何操作),并建议使用 .deb 包作为替代方案。
在显示错误之前我如何实现这样的消息? 有没有办法在不解包和重新打包的情况下将自定义脚本添加到 AppImage 的 AppRun 中?
有没有办法在不解包和重新打包的情况下将自定义脚本添加到 AppImage 的 AppRun 中?
@gcascio线程中有关于使用类似加载程序的 sh 脚本的消息,该脚本可以由afterpack脚本注入。
感谢您的回复。 但是我认为在调用afterpack
时生成的 AppRun 不可用还是我错了,至少我在appOutDir
找不到它?
我认为调用 afterpack 时生成的 AppRun 不可用
我写的是使用类似加载程序的 sh 脚本,而不是修补 AppRun 脚本。 如果您想修补 AppRun 脚本,如果不重新打包似乎没有办法做到这一点。
好吧,我误解了。 我可能会重新打包然后谢谢。
我可能会重新打包然后谢谢。
@gcascio在您需要模板的情况下。
ia 相同的“找到 SUID 沙箱助手二进制文件”错误,但在安装后出现在 snap 文件上
如何解决这个问题
@vladimiry我正在一个名为http://gitpod.io的在线 IDE Docker 中工作,该 IDE Docker 运行着一个 Debian 容器。 我无法修复 chrome-sandbox 问题,因为我没有 sudo 访问权限。 这里的总体基调是,这是 Chrome 问题而不是 Electron 问题,但是如果 Electron 可以解决问题,那不是一件好事吗?
从这个站点https://www.gitpod.io/blog/gitpodify/我看到了在容器中使用 Puppeteer 的解决方案。
const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});
如果发生沙箱错误,在终止进程之前,Electron 可以尝试一些类似的代码吗? 或者这是我可以用 bash 文件调用的东西?
如果发生沙箱错误,在终止进程之前,Electron 可以尝试一些类似的代码吗? 或者这是我可以用 bash 文件调用的东西?
是的,通常将--no-sandbox
参数传递给电子应用程序二进制文件应该可以解决这个问题。
根据安装包,您可以将 SUID 权限位 (4755) 设置为chrome-sandbox
二进制(对于 deb、pacman 等包)或将--no-sandbox
参数硬编码到加载程序 sh/bash 脚本(对于像 Snap 和 AppImage 这样的包)。 这就是我目前所做的,因此不需要为应用程序用户做任何事情(不需要 sudo 访问权限)。
最近的电子构建器版本已经对--no-sandbox
参数进行了硬编码,但仅适用于 Snap 包。
谢谢@vladimiry electron --no-sandbox 似乎解决了这个问题。 我也会结帐 SNAP。
有更新的电子构建器,但 AppImage 仍未修复,对吗?
电子 6 是否正在修复沙箱错误? 我仍然使用 v4,因为我无法解决这个问题,无论是 5 还是 6。
这是情况:
CLONE_NEWUSER
的操作系统功能。 出于谨慎考虑,某些内核使用此功能构建时仅限于特权用户。 您可以在此处阅读更多相关信息 [lwn, 2016]。CLONE_NEWUSER
不可用时,Chromium 会回退到使用不同的沙盒机制,该机制需要一个 setuid 到 root 的辅助二进制文件。 如果此二进制文件不存在或没有正确的权限( 4755
_and 由 root_ 拥有),沙箱将无法启动。npm install
上设置这些权限,因为我们不想在npm install
期间请求 root 访问权限。有两种解决方法:
CLONE_NEWUSER
非特权访问。 一些内核支持用sysctl kernel.unprivileged_userns_clone=1
改变它。--no-sandbox
完全禁用沙箱。 不幸的是,从 JS 中添加这个参数是不够的,因为 GPU 进程在主进程 JS 运行之前启动。当检测到这些情况时,我们将不支持在 Electron 中自动禁用沙箱。 您必须确保为您的分发包设置了适当的权限。 大多数工具(至少electron-builder、electron-installer-snap、electron-installer-debian和electron-installer-redhat)自动支持这一点,不需要开发人员进行配置。 如果您使用的其他工具不支持此功能,请在该工具上提出问题并链接到此评论。
我正在关闭这个问题,因为如上一段所述,除非另有明确指示,否则我们不会更改生产环境中的 Electron 需要访问功能沙箱的要求。 然而,为了简化开发,我打开了 #19550 来跟踪当 Electron 通过npm install
安装时自动降级到非沙盒模式的选项,而不是通过分布式包。
@p3x-robot 您可以找到解决方法 2 的最小示例。@nornagon在这里提到,其灵感来自 @vladimiry
@gcascio但我可以删除 snap hack 对吗? 随着电子生成器中的快照完成,您能确认一下吗?
@gcascio它有效,非常感谢! 有用!
@gcascio没有工作,它生成 2 个图标,所以我恢复到电子 v4.2.8... :(
@p3x-robot 感谢您的反馈。 如果你感兴趣,我已经创建了一个问题,我会尽快找到一些时间。
@nornagon所以我们甚至无法在 Debian 上运行 Electron 6,而且我们无法提供 chrome 进程根权限。 从用户的角度来看,给出的解决方法是不够的。
有两种解决方法:
在内核中启用对 CLONE_NEWUSER 的非特权访问。 一些内核支持使用 sysctl kernel.unprivileged_userns_clone=1 更改此设置。
绝对没有办法弄乱客户的计算机是解决此问题的方法。
通过使用 --no-sandbox 启动来完全禁用沙箱。 不幸的是,从 JS 中添加这个参数是不够的,因为 GPU 进程在主进程 JS 运行之前启动。
添加--sandbox
标志并默认关闭沙箱功能怎么样? 这样做的好处是不会让99% 的人使用 Electron。
从用户的角度来看,给出的解决方法是不够的。
使用类似加载程序的脚本/程序将添加--no-sandbox
arg 也可以被视为一种解决方法,因此不需要最终用户操作。 除了这样的加载器可以首先测试user namespace
支持,并仅在需要时添加--no-sandbox
。
@pronebird提供 chrome-sandbox 二进制 setuid root 比在没有沙箱的情况下运行 Electron 危险得多。 考虑:_你是_传送Electron二进制文件的人,所以你可以确信你传送的是受信任的代码(例如通过签名)。 但是,如果您的应用程序可以被说服加载不受信任的代码(可能是故意的,例如通过导航到网络上的 URL),那么该应用程序将很乐意在用户许可的情况下执行该代码,而无需任何类型的沙箱。 我更关心防御攻击的重点是在您的应用程序中的非沙盒进程中运行不受信任的 JS,而不是涉及利用 Chrome 使用的同一沙盒系统中的错误的攻击。 (如果发现后者,我希望后者能够_非常快地_得到修复。)如果您想自己审核chrome-sandbox
二进制文件的代码,您可以从这里开始: https://chromium.googlesource。 com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424
如果您致力于在没有 Electron 沙箱的情况下运行,我强烈建议您使用其他方式进行沙箱处理,例如 snapcraft 或 flatpak,我认为这些打包程序包括在容器内禁用 Electron 沙箱的启动器脚本。
@nornagon
给予 chrome-sandbox 二进制 setuid root 比在没有沙箱的情况下运行 Electron 的危险要小得多。 考虑一下:您是传送 Electron 二进制文件的人,因此您可以确信自己正在传送受信任的代码(例如,通过对其进行签名)。 但是,如果您的应用程序可以被说服加载不受信任的代码(可能是故意的,例如通过导航到网络上的 URL),那么该应用程序将很乐意在用户许可的情况下执行该代码,而无需任何类型的沙箱。 我更关心防御攻击的重点是在您的应用程序中的非沙盒进程中运行不受信任的 JS,而不是涉及利用 Chrome 使用的同一沙盒系统中的错误的攻击。 (我希望后者如果被发现,会很快得到修复。)
当然,但是如果您的应用程序从不加载任何远程内容,那么运行沙箱就没有意义了。 我相信 Electron 必须如此——使用网络堆栈构建桌面应用程序,从网络加载 JSON,但不像我们没有 Safari 那样只显示网页。 我们已经过去了人们过去常常将网站包装在电话间隙中的时代,不是吗?
我认为开销太大了。 我今天在我们的应用程序中添加了一个引导脚本,并从分发中删除了chrome-sandbox
二进制文件,这是另外 5 兆。 不幸的是electron-builder
不支持任何这些,所以我们不得不添加一个钩子并自己做。
如果您想自己审核 chrome-sandbox 二进制文件的代码,可以从这里开始: https :
谢谢。 这实际上取决于威胁模型,我们无法以 root 权限运行任何 Google。
它可以是完全安全的,但也很难验证所有源是否完整,因为电子构建是通过 npm 发送的。 我们必须为 Electron 设置自定义构建服务器并自己审核源代码。 这将是一项巨大的努力,我宁愿避免它。
@pronebird我不会过多参与沙盒讨论,但我的立场是我们应该像目前一样默认启用沙盒。
它可以是完全安全的,但也很难验证所有来源是否完整,因为电子构建是通过 npm 发送的
这从根本上是不正确的,电子构建不是通过 npm 发送的。 npm 上的electron
包实际上大约有 2 个文件和约 40 行 JS。 实际的 Electron 构建是通过 S3 交付的,并且在 S3 上也有校验和,因此人们可以验证他们正在下载的构建实际上是 Electron 交付的构建。
@MarshallOfSound
这从根本上是不正确的,电子构建不是通过 npm 发送的。 npm 上的电子包实际上大约有 2 个文件和约 40 行 JS。 实际的 Electron 构建是通过 S3 交付的,并且在 S3 上也有校验和,因此人们可以验证他们正在下载的构建实际上是 Electron 交付的构建。
我的意思是,构建是在npm install
阶段下载的。 我并不是说它们物理托管在 npm 上。 假设它们托管在 S3 上。 证明我错了,但我打赌校验和托管在同一个 S3 上,这降低了此类系统的安全等级,这只是一条腿。 但这不是重点。 想象一下您的构建被篡改并相应地更新校验和的场景。 现在我们有一个问题。 这只是我这边的风险和损害控制。 无根 = 发生非常糟糕的事情的风险较低。
@pronebird chrome-sandbox 二进制文件绝对不应该是 5MB,这是一个错误。 打开 #20049 修复它,感谢您指出。
您当然可以选择为您的用例禁用沙箱。 不幸的是,Chromium 的架构使您必须直接在命令行上传递--no-sandbox
而不是调用app.commandLine.appendSwitch
; 理想情况下,可以在不需要包装器脚本的情况下禁用沙箱。 希望通过 #20049 删除二进制文件的问题会得到改善,因为 200KB 比 5MB 更合理。
是否有使用系统二进制文件的选项? 我对为 node_modules/ 文件夹中的任何内容提供 suid 根位持保留态度。 谢谢。
@gardner您可以传递--no-sandbox
arg,当您处于开发模式时,这是一种简单的解决方法。
VSCode 刚刚切换到 Electron 6,现在我们收到报告说除非提供--no-sandbox
选项,否则 VSCode 将不再启动。 这里的前进方向是什么? 参考: https :
snap 现在是开箱即用的,对于 appimage,有一个硬写的代码:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676
其余的我不知道,我只发布 NPM、AppImage 和 SNAP...
基本上,您必须重新打包每种类型的项目以将参数 ( --no-sandbox
) 添加到启动程序脚本。
我猜 Electron 6 上没有解决方案,要么你必须根据你的包编写它,要么等待修复或降级......
为了更好的开发者体验。 我们可以在电子 cli 工具中设置如下命令。
sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted
像电子 --ConfigSandbox 这样的命令。
用户将意识到并且可以轻松配置沙箱。
即使它是第一次运行。 我们可以询问他们是否愿意采取行动。 是或否。 然后他们需要做的就是输入密码。 这样它就会一目了然。 它将带来巨大的用户体验并及时取胜。 因为您会信任供应商或社区。 并随它去。 代替全网搜索。 这对于我们这些初学者来说更有价值。 在所有情况下都很好。
此问题已关闭,但我仍然使用电子 7.0.0 。 是否有导致修复的提交?
为什么问题被关闭了? 似乎没有可用的修复程序,因为即使在 v7.0.0 中它仍然存在
因为这是打包应用程序的问题,而不是 Electron 的问题。
啊,好的。 但是我该如何解决这个问题呢? 有什么方法可以让最终用户不必做任何额外的工作?
有什么方法可以让最终用户不必做任何额外的工作?
是的,有办法,之前已经讨论过了。
须藤 sysctl kernel.unprivileged_userns_clone=1
WSL 用户存在问题(有很多人使用 WSL)并且 WSL 1 不使用实际的 linux 内核......我们将不得不等待 WSL2 发布。
有关此限制的参考: https :
CONFIG_USER_NS=y 启用用户命名空间功能,但默认情况下它们仍然仅限于特权用户。 这表明 sysctl kernel.unprivileged_userns_clone=1
我确认执行
sudo sysctl kernel.unprivileged_userns_clone=1
是另一种解决方法,相关评论。
是的,我使用 manjaro 和 i3wm,我犯了同样的错误,但它正在工作。
我是否遗漏了什么,或者不再可能在没有 root 访问权限的情况下简单地下载和运行 Electron 应用程序? 抱歉,我没有意识到这是 Debian 特有的,而且主线内核甚至不支持禁用非特权命名空间。
请原谅我的大胆,但这绝对是疯了。 即使在渲染器进程中,Electron 也公开了 Node.js API。 在 Electron 应用程序中使用/启用 Chromium 的沙箱是完全没有意义的,正如你们都可以从 GitHub 周围指向这个问题的错误报告中看到的那样,它也非常适得其反。 如果可能,请禁用它。
即使在渲染器进程中,Electron 也公开了 Node.js API。
nodeIntegration
选项自 v5 起默认禁用。
抱歉,我没有意识到这是 Debian 特有的,而且主线内核甚至不支持禁用非特权命名空间。
所以运行 debian,我似乎很幸运我在我的机器上有 root 访问权限。 但是我是否正确地认为这个功能会阻止用户在没有的情况下运行电子应用程序(作为 AppImage)
a) 有sudo
,或
b) 能够说服拥有sudo
人启用非特权命名空间?
@black-puppydog 好吧,如果他们从源代码构建应用程序,他们可以编辑启动脚本以将--no-sandbox
参数传递给电子。 应该可以修改具有相同效果的 AppImage(通过解包和重新打包),但我自己没有尝试过。 某些 AppImage 创建者在其构建中包含该标志也并非不可能,在这种情况下,这些特定图像将正常工作。
否则,我认为你是对的。 请注意,主线内核始终启用非特权名称空间,并且无法禁用它们。 因此,为什么这只是 Debian 上的一个问题。
@black-puppydog 我记得,当你第一次在你的机器上安装 Debian 时,安装程序会提示你输入 root 密码。 但是是的,在 Debian(或任何其他使用 Debian 内核补丁的系统)上,您需要具有 root 访问权限(通过sudo
或其他方式),或者使用--no-sandbox
运行 Electron 应用程序。
@ndorf在主线 Linux 中,可以通过不在功能中编译来禁用用户命名空间,但不能在运行时启用/禁用它们或仅限于特权进程。 Debian 为其内核打补丁,这样默认情况下用户命名空间仅限于特权进程,但可以通过/proc/sys
下的设置为所有进程启用。
Debian 限制它的原因是非特权用户命名空间是一个严重的安全风险,具有悠久的漏洞历史。 非特权用户命名空间允许非特权进程访问许多内核功能(UID 0、功能、挂载文件系统、创建设备 inode 等),这些功能在很长一段时间内仅限于特权进程使用。 任何内核代码依靠假设非特权进程将永远无法做这些事情现在是脆弱的是特权进程突然有能力做这些事情。
在每个 linux 发行版都启用这些功能之前,是否有可能的解决方法?
看原文:
如果我 chown 和 chmod 文件然后它工作正常
另请参见此处#16631(评论)因此,要使 suid 沙箱工作,您基本上必须以这种方式调整
chrome-sandbox
二进制文件:* `sudo chown root chrome-sandbox` * `chmod 4755 chrome-sandbox`
这个问题更严重,但如果运行 appimage/snap 包,我还没有为这些情况透露一个像样的解决方法。 如果 appimage 使用
--no-sandbox
argumnt 执行,它就可以工作,但这是一个 hack。
如果我从未打包的目录中执行应用程序,这会起作用。 更改chrome-sandbox
的权限后如何打包这个目录?
这怎么还没解决
snap 已修复,我有自己的构建,可与 appimage 配合使用。 因为其余的没有解决。
这个线程非常长,仍然遇到错误。 是否有任何地方的情况摘要? 也许这样的摘要可以与错误相关联。
这听起来像https://github.com/electron/electron/issues/17972#issuecomment -495767027 和类似的提议,只有在具有 root 访问权限的系统上才能轻松安全地拥有电子功能就足够了。 如果系统检测到不正确的权限设置并向开发人员提供警告,以减少用户遇到此问题,也许会很好,但也许这是一个单独的问题。 如果没有root访问权限的用户可以轻松使用电子,并且清楚地认识到不受信任的资源比平常更危险,那似乎也很好。
没有root访问权限的用户可以轻松使用电子的路径
--no-sandbox
CLI 参数。
vladimiry,我在考虑例如没有太多终端经验的最终用户,或者运行包装电子的应用程序
我在考虑例如没有太多终端经验的最终用户,或者运行包装电子的应用程序
将--no-sandbox
嵌入应用程序快捷方式。 无论kernel.unprivileged_userns_clone
系统值如何,此处的任何 Linux 软件包都可以正常运行。 所以这是一个打包应用程序的问题。
如果我是一名开发人员,并且向我的最终用户发出适当的警告,那就是正确的。 由于命名空间沙箱为他们工作,很多开发人员不会永远不会了解这个问题吗? 同样令人担忧的是,现有的解决方案没有与相关人员沟通,即不受信任的资源更危险。
此解决方案仅在由于 WSL 而出现此错误时才有效
我在尝试在 WSL 上使用electron
时遇到了这个问题(我的情况是 WSL2)。
即使使用 X11 服务器,Electron 也无法在 X11 上运行。
我必须为 Windows 构建电子,即使我在 WSL 中运行它。 之后,一切正常
最简单的方法:
npm uninstall electron
export npm_config_platform=win32
npm install electron
unset npm_config_platform
这表明
sysctl kernel.unprivileged_userns_clone=1
我看到 WSL(Windows 10)存在这个问题,Ubuntu 18.04 安装到 WSL。
sudo sysctl kernel.unprivileged_userns_clone=1
不起作用。
sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory
使用 chown 和 chmod 也不是一种选择。
@MarshallOfSound zip 不支持权限,但最终问题不是 chmod 权限,而是所有者。 setuid 沙箱助手是 suid _to root_,因为它需要执行只有 root 才能使用的功能。 如果不先获得root权限就可以设置适当的权限,那将是Linux中一个非常严重的漏洞。 对 Linux 来说幸运的是,对我们来说不幸的是,情况并非如此。
zip _does_ 支持基于 unix 的系统(或至少在我测试过的 linux 变体上)的权限。 见https://serverfault.com/a/585889/17620
权限位存储在 zip 的中央目录的文件头后缀中。 后缀的externalFileAttributes
字段可用于存储每个文件/目录条目的权限位。
抄送@MarshallOfSound
我也有同样的问题 !
[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]$
以普通用户身份运行,出现错误: FATAL:setuid_sandbox_host.cc(157)]
以root身份运行,出现错误: FATAL:electron_main_delegate.cc(211)]
但是当我在 yum install snap 之后,以 root 或普通用户运行就可以了。
sudo chown root chrome-sandbox
sudo chmod 4755 chrome-sandbox
这很好用。
@cuixiping它有效:+1:
我做了
$ 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
我在 Deepin 上运行电子时遇到了同样的问题,我已经用这段代码解决了这个问题
electron . --no-sandbox
希望对你有帮助
不起作用
@tushar-compro,这里是https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack。 基本上,我在打包后脚本中为某些包类型设置了 4755 位,并且仍在重新打包 appimage+snap 包。 实际上,电子制造商已经将--no-sandbox
arg 嵌入到 snap 中,但尚未嵌入 appimage https://github.com/electron-userland/electron-builder/pull/4496。 买的方式,这些天电子制造商已经设置了 4755 位https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl #L7。 所以最近的电子构建器版本应该为大多数开发人员简化事情。
@弗拉迪米里
我是正确理解您所设定的4755位对目标以外的其他appimage和捕捉。
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17
但是在 debian 发行版上使用 .appimage 安装程序时会出现问题。
我在这里错过了什么吗?
但是在 debian 发行版上使用 .appimage 安装程序时会出现问题。
正如我所说,appimage 仍然需要特殊处理。 我重新打包并将--no-sandbox
嵌入到./AppRun
脚本中。 在此处找到DISABLE_SANDBOX_ARGS_LINE
关键字https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts。
但是在 debian 发行版上使用 .appimage 安装程序时会出现问题。
正如我所说,appimage 仍然需要特殊处理。 我重新打包并将
--no-sandbox
嵌入到./AppRun
脚本中。 在此处找到DISABLE_SANDBOX_ARGS_LINE
关键字https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts。
最新的电子构建器会自动处理 snap 和 appimage 中的 no sanbox 参数。
@弗拉迪米里
因此,我是否正确理解您所做的 4755 位设置适用于 appimage 和 snap 以外的安装程序。 而对于 appimage,您已经设置了无沙箱。 你能确认一下吗。
@p3x-机器人
是的。 你说对了一部分。
最新的电子构建器会自动处理 snap 和 appimage 中的 no sanbox 参数。
无法在他们的代码还没有找到appimage特定片断类似这样一个适用于捕捉(https://github.com/electron-userland/electron-builder/pull/4496仍处于打开状态)。 无论如何,在我的情况下仍然需要重新打包,因为我在那里添加了额外的参数,而不是与 sanbox 相关的参数。
因此,我是否正确理解您所做的 4755 位设置适用于 appimage 和 snap 以外的安装程序。 而对于 appimage,您已经设置了无沙箱。 你能确认一下吗。
正确的。 但是现代电子制造商在内部设置了 4755。 我检查它是否没有设置为 snap/appimage,因为那将是一个错误。 例如,如果我没记错的话,snap 不会以 4755 位设置为电子二进制开始。
@弗拉迪米里
我只需要设置 no-sandbox,因为我的 appimages 在 debian 中不起作用。
我相信在这种情况下我不需要重新打包。 但是我找不到正确的电子生成器文档来执行此操作。 或者你认为我还需要重新打包吗?
你能指点我正确的文档,它可以帮助我如何做到这一点。
此外,我知道我有两个选项,要么设置 4755 位,要么设置无沙箱。
你觉得哪个更好?
此外,我知道我有两个选项,要么设置 4755 位,要么设置无沙箱。
如果我没记错的话,appimage 的设置 4755 不会解决问题。 您需要(其中之一):
--no-sandbox
命令行参数启动您的 appimage 文件--no-sandbox
嵌入到位于您的 appimage 文件中的./AppRun
脚本中(因此需要重新打包)。你能指点我正确的文档,它可以帮助我如何做到这一点。
我怀疑您是否会在任何文档中找到有关该问题的详细信息。 我不知道任何相关的文档。
此外,我知道我有两个选项,要么设置 4755 位,要么设置无沙箱。
如果我没记错的话,appimage 的设置 4755 不会解决问题。 您需要(其中之一):
- 以
--no-sandbox
命令行参数开始- 将
--no-sandbox
嵌入到 appiamge 文件中的./AppRun
脚本中(因此需要重新打包)。你能指点我正确的文档,它可以帮助我如何做到这一点。
我怀疑您是否会在任何文档中找到有关该问题的详细信息。 我不知道任何相关的文档。
电子生成器最新将--no-sandbox
嵌入到./AppRun
,我曾经重新打包,但现在它没用了,我只使用原生电子生成器。
@弗拉迪米里
是的。 单独设置 4755 是行不通的。 使用 4755,我们需要将 chrome-sandbox 的所有者更改为 root。
无论如何,非常感谢您的帮助。 我会尝试参考您的代码并设置无沙箱。
@p3x-机器人
您能否分享一些链接(电子生成器存储库),我们可以在其中看到执行此操作的代码。
https://github.com/patrikx3/onenote
@弗拉迪米里
是的。 单独设置 4755 是行不通的。 使用 4755,我们需要将 chrome-sandbox 的所有者更改为 root。
无论如何,非常感谢您的帮助。 我会尝试参考您的代码并设置无沙箱。@p3x-机器人
您能否分享一些链接(电子生成器存储库),我们可以在其中看到执行此操作的代码。
最新的electron builder在./AppRun中嵌入了--no-sandbox,我以前是重新打包的,现在没用了,就用原生的electron builder。
我刚刚使用最新的电子构建器版本对其进行了测试,它没有在 ./AppRun sh 脚本中嵌入 --no-sandbox。 如果您启动 appimage,它会因已知的[759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found
错误而失败。 也许您的系统上启用了kernel.unprivileged_userns_clone
标志。 如果是这样,请尝试像sudo sysctl kernel.unprivileged_userns_clone=0
一样禁用它并再次启动 appimage 文件。
最新的electron builder在./AppRun中嵌入了--no-sandbox,我以前是重新打包的,现在没用了,就用原生的electron builder。
我刚刚使用最新的电子构建器版本对其进行了测试,它没有在 ./AppRun sh 脚本中嵌入 --no-sandbox。 如果您启动 appimage,它会因已知的
[759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found
错误而失败。 也许您的系统上启用了kernel.unprivileged_userns_clone
标志。 如果是这样,请尝试像sudo sysctl kernel.unprivileged_userns_clone=0
一样禁用它并再次启动 appimage 文件。
奇怪的是,最新的电子生成器有 10k 快照安装。 毫无疑问,电子构建器表明它添加了该标志......
有 10k snap
我们在谈论 appimage,而不是 snap 东西。 Snap当然嵌入了我上面提到的arg,这里https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L199 -L202。
有 10k snap
我们在谈论 appimage,而不是 snap 东西。 Snap当然嵌入了我上面提到的arg,这里https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L199 -L202。
你说的对。 我在想由于某种原因它是在 appimage 中完成的,我什至删除了重新打包的代码并添加了无沙箱,但我再试一次,发现它丢失了,所以我添加了我的构建恢复,不作品。 抱歉,在我的 corifeus-builder 中,您可以看到我在做什么: https :
嗨@nornagon考虑到这个问题有多普遍,官方电子快速入门教程是否可以更新以包含解决方法,以便新手获得积极的体验?
编辑:感谢社区的鼓励,我打开了一个 FR #26478
@gabefair这似乎是一个合理的提议。 您有兴趣开设 PR 吗?
最有用的评论
CONFIG_USER_NS=y
启用用户命名空间功能,但默认情况下它们仍然仅限于特权用户。 这表明sysctl kernel.unprivileged_userns_clone=1