Electron: Обнаружен вспомогательный двоичный файл песочницы SUID, но он настроен неправильно

К сожалению, мы не можем правильно настроить это автоматически, потому что для установки соответствующих разрешений требуются привилегии root, и мы не хотим запрашивать пароль root во время npm install .

В идеале 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 arguemnt, но это взлом.

@nornagon

потому что для установки соответствующих разрешений требуются привилегии root, и мы не хотим запрашивать пароль root во время установки npm.

Выполнение chmod 4755 node_modules/electron/dist/chrome-sandbox не требует прав root, и этого должно быть достаточно, чтобы запустить такую ​​команду для переноса приложения в пакеты deb / pacman / etc, когда такие пакеты устанавливаются, как правило, все файлы, включая chrome-sandbox принадлежит root. Так что было бы здорово, что электрон автоматически выполняет 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 Если мы chmod 4755 out/Release/chrome-sandbox на CI, будет ли это разрешение сохранено после того, как мы zip его включим, или нам нужно будет внести это изменение в electron-download чтобы исправить разрешение на DL?

то же самое вот плохая новая функция для того, что нужно изменить это ... :(

@MarshallOfSound zip не поддерживает разрешения, но в конечном итоге проблема заключается не в разрешении chmod, а в владельце. Помощник setuid для песочницы - это suid _to root_, потому что он должен выполнять функции, доступные только root. Если бы можно было установить соответствующие разрешения без предварительного получения привилегий root, это было бы очень серьезной уязвимостью в Linux. К счастью для Linux, но, к сожалению, для нас это не так.

Вот варианты, которые я вижу:

1. Ничего не меняйте в Электроне. Рекомендуем разработчикам включить непривилегированный CLONE_USERNS в своем ядре, чтобы разрешить запуск изолированной программной среды пространства имен вместо изолированной программной среды setuid.
2. Загрузитесь без песочницы, если метод песочницы недоступен _только при загрузке неупакованного приложения_. Если Electron загружает упакованное приложение, откажитесь от загрузки без песочницы.
3. Во всех случаях, если метод песочницы недоступен, загрузитесь без песочницы и выведите предупреждение.
4. Отключите песочницу по умолчанию в Linux.

Я склоняюсь к (2). Это упростило бы разработку без ущерба для безопасности развернутого приложения.

Я еще не уверен, что делать с snap / flatpak, так как я не знаком с их работой. Возможно, они уже достаточно изолировали приложение, чтобы мы могли полностью отключить песочницу в этой ситуации, как мы это делаем при создании версии Electron для Mac App Store.

А пока мне больше нравится первый вариант.

1. Загрузка без песочницы, если метод песочницы недоступен, только при загрузке неупакованного приложения. Если Electron загружает упакованное приложение, откажитесь от загрузки без песочницы.

Такой сценарий как-то вводит в заблуждение. Можно успешно запустить распакованное приложение без песочницы, но есть вероятность, что упакованное приложение не будет работать таким же образом с включенной песочницей. Как, например, случай, когда вы обращаетесь к основному процессу из процесса рендеринга не через интерфейс remote . Или случай упаковки приложения в пакеты AppImage / Snap / Flatpak.

1. Во всех случаях, если метод песочницы недоступен, загрузитесь без песочницы и выведите предупреждение.

Таким образом, упакованное приложение, которое было спроектировано и разработано как изолированное, может быть выполнено без песочницы, если песочница недоступна. Мне это не нравится.

1. Отключите песочницу по умолчанию в Linux.

Что именно это означает? Каким будет способ включить песочницу в Linux при запуске или отказе приложения, если песочница недоступна (текущая ситуация, принудительная песочница).

Мне также нравится (1), но чтобы немного защитить (2), API, доступный для приложения, не изменится при отключении песочницы. Единственное, что мы отключим, - это песочница на уровне ОС. Мы все равно загрузим приложение таким же образом, просто оно не будет защищено ОС.

Мы все равно загрузим приложение таким же образом, просто оно не будет защищено ОС.

Тогда это звучит хорошо и для меня. Спасибо за объяснение.

Мне не нравится 2., потому что дополнительная безопасность обычно приводит к тому, что люди ее отключают.

Попав на место «глупого пользователя», я бы предпочел, чтобы Electron работал по умолчанию. Если это очень важная мера безопасности, предупредите меня и подробно объясните, почему мне нужно выполнять дополнительную работу. Если это не так важно, не надо мне дурной вкус «не работает».

Из-за этого мне нравится 1. (с форсировкой бросить, как сейчас) или 4.

: x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox вызывает у меня тревогу.

Просто чтобы прояснить, что он делает: он устанавливает бит SUID на chrome-sandbox , что позволяет _ любому пользователю_ выполнять файл _ как 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).

Просто чтобы прояснить, что он делает: он устанавливает бит SUID на chrome-sandbox , что позволяет _ любому пользователю_ выполнять файл _ как root_. Это означает, что если существует какой-либо способ злонамеренного использования chrome-sandbox или если содержимое когда-либо становится вредоносным, любой пользователь может стать пользователем root. chrome-sandbox будет очень интересной целью для атаки.

Да, но этот двоичный файл точно такой же, что и в Chrome, поэтому, если вы беспокоитесь об этом, вам, вероятно, также следует удалить Chrome :)

Есть ли способ запустить без песочницы / запустить без "помощника по песочнице"? Получили жалобы первых пользователей 😅
Я ожидал, что это отключит песочницу, но по-прежнему получаю ошибку The SUID sandbox helper binary was found, but is not configured correctly .
Я бы не хотел откатиться на electronic 4.x 🤨

Сообщение об ошибке

Обзор Snapcraft и suid

Я попытался загрузить оснастку с флагом suid на chrome-sandbox но процесс проверки из 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'

@thomasnordquist для отключения песочницы на уровне ОС --no-sandbox необходимо передать в качестве аргумента приложения, то есть app.commandLine.appendSwitch будет недостаточно. Что касается пакета Snap, вы можете попробовать добавить плагин, как описано здесь . Не уверен, что это поможет, так как я еще не пробовал, было бы здорово, если бы вы это сделали. Сейчас я предпочитаю выпускать созданное мной приложение в смешанном режиме : smile :. Electron v5 используется для всех пакетов, кроме AppImage и Snap, поскольку еще не совсем понятно, как заставить эти пакеты работать с включенной песочницей, но в какой-то момент это станет ясно.

Если Snapcraft запрещает suid-флаги, то, вероятно, единственный вариант - полностью отключить песочницу Electron в Snapcraft и полагаться на контейнер, который использует Snapcraft. Я не уверен, как лучше всего это сделать - можно ли указать дополнительные флаги командной строки при упаковке через Snapcraft? Если это так, мы могли бы добавить флаг --no-sandbox . В противном случае нам может потребоваться добавить какой-то конкретный механизм обнаружения для обнаружения работы в Snapcraft / Flatpak и отключить песочницу на основе этого обнаружения.

Некоторая документация по Snap https://docs.snapcraft.io/browser-support-interface

@ posix4e Не могли бы вы пролить свет на проблему запуска изолированного пакета Snap как в пользовательском пространстве имен, так и в режиме песочницы / резервной копии SUID? Похоже, у вас есть соответствующий опыт настройки конфигурации оснастки Brave Browser. CC @flexiondotorg.

Просто чтобы прояснить, что он делает: он устанавливает бит SUID на chrome-sandbox , что позволяет _ любому пользователю_ выполнять файл _ как root_. Это означает, что если существует какой-либо способ злонамеренного использования chrome-sandbox или если содержимое когда-либо становится вредоносным, любой пользователь может стать пользователем root. chrome-sandbox будет очень интересной целью для атаки.

Да, но этот двоичный файл точно такой же, что и в Chrome, поэтому, если вы беспокоитесь об этом, вам, вероятно, также следует удалить Chrome :)

Меня отчасти беспокоит, что в двоичном файле из Chrome будет root:root с установленным SUID, да. Очень мало кода без ошибок. Вот исходный код для записи: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Но меня больше беспокоит, если npm install :

1. Загрузите множество программного обеспечения на лету.
2. Автоматически сделать один из файлов root:root и SUID.

Я думаю, что это будет первый программный стек, о котором я знаю, который автоматически выполняет sudo chown root:root && sudo chmod 4755 для файла, принадлежащего пользователю без полномочий root.

О выполнении sudo chown root:root && sudo chmod 475 при установке npm не может быть и речи, npm нужно будет запускать от имени root, чтобы установить разрешения. Модель хуков npm позволит всем установленным пакетам также запускать свои хуки от имени пользователя root. Возможно, с сотнями пакетов и вложенными зависимостями это было бы очень опасно.

Выполнение sudo chown root: root && sudo chmod 475 при установке npm не может быть и речи

Насколько я понимаю, это не рассматривается как вариант.

Я согласен с тем, что делать что-либо, для чего требуются привилегии root во время установки npm, не нужно начинать. Вот почему я не указал это как один из вариантов .

Что бы это ни стоило, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0 и electron-installer-snap 3.2.0 были выпущены с изменениями песочницы SUID. Бета-версии Electron Forge v5 и v6 также должны быть обновлены временно (через обновления версии в пределах диапазона, используйте 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 неправильно пытается использовать песочницу пространства имен в докере, хотя он должен пытаться использовать песочницу suid. Я не уверен, почему это так, но вы можете принудительно запустить песочницу suid с помощью --disable-namespace-sandbox . Если вы запустите докер с --privileged (или --cap-add SYS_ADMIN , или пользовательский профиль seccomp, который позволяет CLONE_NEWUSER), тогда пространства имен будут доступны внутри песочницы, и нет необходимости в песочнице setuid или ее вспомогательном исполняемом файле. .

Как и @thomasnordquist, я отключил песочницу для пакетов Snap / AppImage с помощью сценария предварительной загрузки. Вы создаете сценарий sh, подобный предварительной загрузке, с именем исходного двоичного файла, который затем используется для загрузки переименованного / исходного электронного двоичного файла с аргументом --no-sandbox . Это удобно сделать в скрипте 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 реализовал поддержку песочницы, сообщите мне об этом в его системе отслеживания проблем.

Если что-то не так с тем, как в electronic-installer-snap реализована поддержка песочницы, сообщите мне об этом в его системе отслеживания проблем.

Я также хотел бы услышать, что кто-то подтвердит, что этого изменения достаточно для решения проблемы с пакетами Snap. Так что приветствуются как положительные, так и отрицательные отзывы. См. Соответствующую информацию .

@vladimiry Я пошел дальше и проверил это, но это не сработало.

Мне нужно решение, которое не решает проблемы с исправлениями ОС, sysctl или перезагрузками. Мне нужно что-то, что просто работает сейчас. --no-sandbox будет предпочтительнее.

Для меня было бы гораздо полезнее, если бы кто-нибудь мог предоставить минимальное приложение Electron, которое я мог бы использовать для воспроизведения нефункционирующего упакованного Snap. Я использовал форк electron-quick-start для создания Snap в CircleCI и установил его на свой ноутбук (Debian Stretch), чтобы убедиться, что мои изменения по крайней мере создали работающее приложение Electron.

«Не сработало» не помогает мне определить, что я могу сделать в electron-installer-snap чтобы он правильно упаковал для других.

@burtonator , спасибо за тестирование. Насколько мне известно, упакованный в загрузчик сборки Snap / AppImage сценарий bash / sh, который запускает исходный двоичный файл / электрон с аргументом --no-sandbox cmd, на данный момент является единственным проверенным обходным путем.

@malept перед тестированием материала необходимо отключить функцию User Namespace OS, выполнив sudo sysctl kernel.unprivileged_userns_clone=0 .

@vladimiry да, на моем ноутбуке уже есть эта настройка пользователя.

Если кто-то ищет решение этой проблемы , решением @thomasnordquist или моей его адаптацией , они работают путем отключения песочницы под Linux.

@fabiospampinato ваша адаптация отключает песочницу для всех типов пакетов Linux, но, по крайней мере, пакеты DEB и Pacman хорошо работают с песочницей SUID (возможно, все пакеты, не похожие на контейнер), просто необходимо установить бит разрешения SUID на chrome-sandbox binary. Но не устанавливайте бит разрешения SUID для пакета Snap, поскольку Snap Store отклоняет такие типы пакетов. Поэтому я установил бит SUID для всех пакетов Linux, кроме пакетов Snap / AppImage, которые отключают песочницу и связанный код .

CONFIG_USER_NS = y включает функцию пространств имен пользователей, но по умолчанию они по-прежнему ограничены привилегированными пользователями. Это предполагает sysctl kernel.unprivileged_userns_clone = 1

Я подтверждаю, что выполнение sudo sysctl kernel.unprivileged_userns_clone=1 - это еще один связанный с этим комментарий обходной путь.

Спасибо, дружище, работаешь на меня! @vladimiry

вы знаете, работает ли теперь с 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 или в документации по

Повторюсь, мое текущее понимание здесь состоит в том, что ошибки, которую нужно исправить, нет, песочница 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 , вы добавляете его следующим образом:

для всех вас, если вы хотите заставить его работать, я создал помощника:

Такое решение уже много раз упоминалось в обсуждении этого вопроса, поэтому я раньше писал, что электрон v5 работает.

@vladimiry спасибо, я пропустил это решение, я просто добавил собственное решение javascript вместо машинописного текста ...

единственная проблема заключается в том, что когда я это после взлома пакета, он не использует на панели значок из электрона, но генерирует второй значок, вы, ребята, как это можно решить? Я думаю, что это делает флаг отсутствия песочницы. кто-нибудь?

это происходит только с --no-sandbox :

@fabiospampinato ваша адаптация отключает песочницу для всех типов пакетов Linux, но, по крайней мере, пакеты DEB и Pacman хорошо работают с песочницей SUID (возможно, все пакеты, не похожие на контейнер), просто необходимо установить бит разрешения SUID на chrome-sandbox binary. Но не устанавливайте бит разрешения SUID для пакета Snap, поскольку Snap Store отклоняет такие типы пакетов. Поэтому я установил бит SUID для всех пакетов Linux, кроме пакетов Snap / AppImage, которые отключают песочницу и связанный код .

вы знаете, как я могу оставить одну иконку вместо двух?

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

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

@ p3x-robot есть способ добавить аргумент --no-sandbox в приложение-контейнер, упакованный в Snap, без использования скрипта bash / sh, подобного прелоадеру:

• Сначала распакуйте оснастку, запустив unsquashfs your-snap-file.snap .
• Отредактируйте ./squashfs-root/command.sh , добавив туда необходимые аргументы.
• Упакуйте папку ./squashfs-root обратно в пакет snap, выполнив команду snapcraft pack ./squashfs-root .

Я не пробовал, но думаю, что аналогичное действие по переупаковке можно применить и к пакету AppImage, то есть к вопросу выполнения различных команд распаковки / упаковки.

Я предполагаю, что описанные действия по переупаковке могут быть запущены в ловушке afterAllArtifactBuild electronics-builder.

@vladimiry , большое спасибо, за то, что интересно для afterAllArtifactBuild, я попробую изменить command.sh без распаковки, но это на завтра, еще раз спасибо!

один интересен для afterAllArtifactBuild

@ p3x-robot afterAllArtifactBuild hook на самом деле не запускается, как я ожидал, но запустить 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:

Надеюсь, это не не по теме, но для AppImages в Debian (9) я получаю сообщение об ошибке:

The setuid sandbox is not running as root. 

Поправьте меня, если я ошибаюсь, но я понимаю (в основном из этого обсуждения), что это вызвано отключенной функцией пространств имен пользователей, которая по умолчанию отключена в Debian.

Итак, что касается этого предложения:

1. Ничего не меняйте в Электроне. Рекомендуем разработчикам включить непривилегированный CLONE_USERNS в своем ядре, чтобы разрешить запуск изолированной программной среды пространства имен вместо изолированной программной среды setuid.

Я хотел бы показать пользователям сообщение о том, что это работает только тогда, когда включена функция пользовательских пространств имен (возможно, с подсказкой, как это сделать), и предложить использовать пакет .deb в качестве альтернативы.

Как я могу реализовать такое сообщение до появления ошибки? Есть ли способ добавить собственный скрипт в AppRun AppImage без распаковки и повторной упаковки?

Есть ли способ добавить собственный скрипт в AppRun AppImage без распаковки и повторной упаковки?

@gcascio в ветке были сообщения об использовании скрипта sh, подобного загрузчику, который может быть внедрен скриптом

Спасибо за ответ. Но я думаю, что сгенерированный AppRun недоступен при вызове afterpack или я ошибаюсь, по крайней мере, я не могу найти его в appOutDir ?

Я думаю, что сгенерированный AppRun недоступен при вызове afterpack

Я писал об использовании сценария sh, похожего на загрузчик, но не об исправлении сценария AppRun. Если вы хотите пропатчить сценарий AppRun, похоже, нет способа сделать это без переупаковки.

Хорошо, я неправильно понял. Пойду перепаковку тогда спасибо.

Пойду перепаковку тогда спасибо.

@gcascio, если вам нужен шаблон .

ia та же ошибка «Обнаружен вспомогательный двоичный файл песочницы SUID», но в файле привязки после установки
как это исправить

@vladimiry Я работаю в онлайн- http://gitpod.io, в котором запущен контейнер Debian. Я не могу исправить проблему с хромированной песочницей, так как у меня нет доступа к 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 binary (для таких пакетов, как deb, pacman и т. Д.) Или жестко закодировать аргумент --no-sandbox для сценария sh / bash загрузчика. (для таких пакетов, как Snap и AppImage). Это то, чем я сейчас занимаюсь, поэтому пользователям приложения не нужно ничего делать (доступ sudo не требуется).

В недавнем выпуске электронного сборщика уже есть жесткое кодирование аргумента --no-sandbox но только для пакета Snap.

Спасибо @vladimiry electronics - решил проблему. Я также проверю SNAP.

есть более новые конструкторы электронов, но AppImage все еще не исправлен, верно?

Электрон 6 исправляет ошибку песочницы? Я все еще использую v4, так как не могу это исправить, ни 5, ни 6.

Вот такая ситуация:

• В Electron v5 включен смешанный режим «песочницы» (т. Е. Некоторые процессы помещаются в песочницу, а другие нет) в Linux. Это не меняет того, являются ли процессы вашего средства визуализации изолированными по умолчанию, но это означает, что процесс GPU теперь изолирован.
• Песочница Chromium в Linux использует функцию ОС под названием CLONE_NEWUSER . Некоторые ядра построены с этой функцией, доступной только привилегированным пользователям из соображений осторожности. Подробнее об этом можно прочитать здесь [lwn, 2016].
• Когда CLONE_NEWUSER недоступен, Chromium возвращается к использованию другого механизма песочницы, для которого требуется вспомогательный двоичный файл с идентификатором root. Если этот двоичный файл отсутствует или не имеет необходимых разрешений ( 4755 _и принадлежит root_), песочница не загрузится.
• Установка бинарных разрешений помощника должна выполняться привилегированным пользователем (например, root). Мы не устанавливаем эти разрешения для npm install , потому что мы не хотим запрашивать root-доступ во время npm install .
• Пакеты выпуска Electron v5 включают вспомогательный двоичный файл, но это зависит от различных инструментов упаковки и распространения, чтобы гарантировать, что он получит правильные разрешения и права собственности.

Есть два обходных пути:

1. Включите непривилегированный доступ к CLONE_NEWUSER в вашем ядре. Некоторые ядра поддерживают изменение этого параметра с помощью sysctl kernel.unprivileged_userns_clone=1 .
2. Полностью отключите песочницу, запустив с --no-sandbox . К сожалению, добавления этого аргумента из JS недостаточно, поскольку процесс GPU запускается до запуска JS основного процесса.

Мы не будем поддерживать автоматическое отключение песочницы в Electron при обнаружении этих условий. Вы должны убедиться, что для ваших распространяемых пакетов установлены соответствующие разрешения. Большинство инструментов (по крайней мере, electronic-builder, electronic-installer-snap, electronic-installer-debian и electronic-installer-redhat) поддерживают это автоматически и не требуют настройки от разработчика. Если вы используете другой инструмент, который не поддерживает это, поднимите вопрос по этому инструменту и дайте ссылку на этот комментарий.

Я закрываю эту проблему, потому что, как упоминалось в предыдущем абзаце, мы не будем изменять требование о том, что Electron в производственной среде требует доступа к работающей песочнице, если явно не указано иное. Однако для облегчения разработки я открыл # 19550, чтобы отслеживать возможность автоматического перехода в режим без песочницы, когда Electron устанавливается через npm install , а не через распределенный пакет.

@ p3x-robot вы можете найти минимальный пример обходного пути 2. упомянутого @nornagon здесь, который вдохновлен @vladimiry

@gcascio, но я могу удалить оснастку, верно? как в электронном конструкторе прорабатывается оснастка, вы можете подтвердить?

@gcascio это работает, большое спасибо! оно работает!

@gcascio no

@ p3x-robot благодарит за отзыв. На случай, если вы заинтересуетесь, я создал проблему и займусь ею, как только найду время.

@nornagon, поэтому мы даже не можем запустить Electron 6 на Debian, и мы никоим образом не даем разрешений root для процесса 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, предоставляющий двоичный setuid root для chrome-sandbox, намного менее опасен, чем запуск 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

предоставление бинарного setuid root для chrome-sandbox гораздо менее опасно, чем запуск Electron без песочницы. Учтите: вы тот, кто отправляет двоичные файлы Electron, поэтому вы можете быть уверены, что отправляете доверенный код (например, подписывая его). Однако, если ваше приложение можно убедить загрузить ненадежный код (возможно, намеренно, например, путем перехода по URL-адресу в Интернете), тогда приложение с радостью выполнит этот код с разрешения пользователя без какой-либо песочницы. Меня гораздо больше беспокоит защита от атак, направленных на запуск ненадежного JS в процессе вашего приложения без тестовой среды, чем в отношении атак, связанных с использованием ошибки в той же системе песочницы, которую использует Chrome. (И я ожидал, что последние будут исправлены очень быстро, если они будут обнаружены.)

Конечно, но запуск песочницы не имеет смысла, если у вас есть приложение, которое никогда не загружает удаленный контент. Я считаю, что это должно быть в случае с Electron - для создания настольных приложений с использованием веб-стека, загрузка, возможно, JSON из Интернета, но не просто отображение веб-страниц, как будто у нас нет Safari для этого. Мы уже прошли те времена, когда люди привыкли оборачивать веб-сайты в разрыв телефона, не так ли?

Я думаю, что накладных расходов слишком много. Сегодня я добавил сценарий начальной загрузки в наше приложение и удалил двоичный файл chrome-sandbox из дистрибутива, который составлял еще 5 мегабайт. К сожалению, electron-builder не поддерживает ничего из этого, поэтому нам пришлось добавить ловушку и сделать это самостоятельно.

Если вы хотите самостоятельно проверить код двоичного файла chrome-sandbox, вы можете начать здесь: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. С # 424

Спасибо. Это действительно зависит от модели угроз, и мы никак не можем запустить что-нибудь Google с правами суперпользователя.

Это может быть совершенно безопасно, но также будет очень сложно проверить целостность всех источников, поскольку электронные сборки отправляются через npm. Нам пришлось бы настроить собственный сервер сборки для Electron и самостоятельно провести аудит источников. Это потребует огромных усилий, и я бы предпочел их избегать.

@pronebird Я не собираюсь слишком вовлекаться в обсуждение песочницы, но моя позиция заключается в том, что мы должны включить песочницу по умолчанию, как мы это делаем сейчас.

Это может быть совершенно безопасно, но также будет очень сложно проверить целостность всех источников, поскольку электронные сборки отправляются через npm.

Это в корне неверно, электронные сборки не отправляются через npm. Пакет electron на npm на самом деле состоит из двух файлов и ~ 40 строк JS. Фактические сборки Electron доставляются через S3 и имеют контрольные суммы также на S3, поэтому люди могут проверить, что загружаемая ими сборка на самом деле является сборкой, поставленной Electron.

@MarshallOfSound

Это в корне неверно, электронные сборки не отправляются через npm. Электронный пакет на npm на самом деле состоит из 2 файлов и ~ 40 строк JS. Фактические сборки Electron доставляются через S3 и имеют контрольные суммы также на S3, поэтому люди могут проверить, что загружаемая ими сборка на самом деле является сборкой, поставленной Electron.

Я имел в виду, что сборки загружаются на этапе npm install . Я не имел в виду, что они физически размещены на npm. Пусть они размещены на S3. Докажите, что я ошибаюсь, но я уверен, что контрольные суммы размещены на одном S3, что снижает уровень безопасности такой системы, это только одна нога. Но дело не в этом. Представьте себе сценарий, в котором ваши сборки изменяются и контрольные суммы обновляются соответствующим образом. Теперь у нас проблема. Это просто контроль риска и ущерба на моей стороне. Нет корня = меньший риск того, что случится что-то действительно плохое.

Бинарный файл @pronebird chrome-sandbox определенно не должен быть 5 МБ, это ошибка. Открыл # 20049, чтобы исправить это, спасибо, что указали на это.

Вы, безусловно, можете отключить песочницу для своего варианта использования. К сожалению, архитектура Chromium заставляет вас передавать --no-sandbox в командной строке напрямую, а не вызывать app.commandLine.appendSwitch ; в идеале отключить песочницу можно без использования сценария-оболочки. Надеюсь, с выпуском # 20049 проблема удаления двоичного файла будет уменьшена, поскольку дополнительные 200 КБ намного разумнее, чем 5 МБ.

Есть ли возможность использовать системный двоичный файл? У меня есть оговорки по поводу присвоения suid root-бита чему-либо в моей папке node_modules /. Спасибо.

@gardner вы можете передать --no-sandbox arg, что является своего рода простым обходным решением, когда вы находитесь в режиме разработки.

VSCode совсем недавно перешел на Electron 6, и теперь мы получаем сообщения о том, что VSCode больше не запускается, если не предоставлена ​​опция --no-sandbox . Какой здесь путь вперед? Ссылки: https://github.com/microsoft/vscode/issues/81056

snap is теперь работает из коробки, для appimage есть жестко написанный код:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

остальное я не знаю, я выпускаю только NPM, AppImage и SNAP ...

По сути, вам нужно повторно упаковать каждый тип элемента, чтобы добавить аргумент ( --no-sandbox ) в сценарий запуска.

Думаю, на Electron 6 нет решения, либо вы должны написать его на основе ваших пакетов, либо дождаться исправления или перехода на более раннюю версию ...

Для лучшего опыта разработчика. Мы можем настроить команду, как показано ниже, в электронном клиенте.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Такая команда как электрон --ConfigSandbox.
Пользователь будет в курсе, и песочницу можно будет легко настроить.
И даже при первом запуске. Мы можем спросить их, хотят ли они принять меры. y или n. И все, что им нужно сделать, это ввести пароль. Таким образом, все будет сделано сразу. И это приведет к большому пользовательскому опыту и выигрышу со временем. Потому что вы будете доверять поставщику или сообществу. И продолжай с этим. Вместо поиска по всей сети. И это даже более ценно для новичков. И это приятно во всех случаях.

Эта проблема была закрыта, но у меня все еще есть электрон 7.0.0. Есть ли фиксация, которая привела к исправлению?

Почему вопрос закрыт? Кажется, что исправления нет, поскольку оно все еще сохраняется даже в v7.0.0

Потому что это вопрос упаковки вашего приложения, а не Electron.

А, ладно. Но как мне это исправить? Есть ли способ, при котором конечному пользователю не нужно выполнять дополнительную работу?

Есть ли способ, при котором конечному пользователю не нужно выполнять дополнительную работу?

Да, способ есть, об этом уже говорилось.

sudo sysctl kernel.unprivileged_userns_clone = 1

Есть проблема с пользователями WSL (есть много тех, кто использует WSL), а WSL 1 не использует фактическое ядро ​​Linux ... нам придется подождать выпуска WSL2.

Для справки об этом ограничении: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS = y включает функцию пространств имен пользователей, но по умолчанию они по-прежнему ограничены привилегированными пользователями. Это предполагает sysctl kernel.unprivileged_userns_clone = 1

Я подтверждаю, что выполнение sudo sysctl kernel.unprivileged_userns_clone=1 - это еще один связанный с этим комментарий обходной путь.

Да, я использую manjaro и i3wm, я взял ту же ошибку, но с этим все работает.

Мне что-то не хватает или больше невозможно просто загрузить и запустить приложение Electron без рут-доступа? Извините, я не понял, что это характерно для Debian, и что основное ядро ​​даже не поддерживает отключение непривилегированных пространств имен.

Простите за смелость, но это абсолютно безумие. Electron предоставляет API Node.js даже в процессах рендеринга. Использование / включение песочницы Chromium в приложении Electron совершенно бессмысленно, и, как вы все можете видеть из отчетов об ошибках на GitHub, указывающих на эту проблему, это также очень контрпродуктивно. Пожалуйста, отключите его, если возможно.

Electron предоставляет API Node.js даже в процессах рендеринга.

nodeIntegration по умолчанию отключен, начиная с версии v5.

Извините, я не понял, что это характерно для Debian, и что основное ядро ​​даже не поддерживает отключение непривилегированных пространств имен.

Итак, запустив debian, мне повезло, что у меня есть root-доступ на моей машине. Но прав ли я, что эта функция как таковая не позволит пользователям запускать электронные приложения (как AppImage или нет) без

а) имея sudo , или
б) возможность убедить кого-то, у кого sudo включить непривилегированные пространства имен?

@ black-puppydog хорошо, если они создают приложение из исходного кода, они могут отредактировать стартовый скрипт, чтобы передать аргумент --no-sandbox в электрон. Должна быть возможность изменить AppImage с тем же эффектом (распаковав и переупаковав его), но я сам этого не пробовал. Также не исключено, что некоторые создатели AppImage включат этот флаг в свои сборки, и в этом случае эти конкретные изображения будут работать.

В остальном, думаю, вы правы. Обратите внимание, что в основном ядре всегда включены непривилегированные пространства имен и нет возможности их отключить. Следовательно, это проблема только Debian.

@ black-puppydog Насколько я помню, программа установки запрашивает у вас пароль root при первой установке Debian на вашу машину. Но да, в Debian (или любой другой системе, использующей патч ядра Debian) вам нужно либо иметь root-доступ (через sudo или иначе), либо запускать приложения Electron с --no-sandbox .

@ndorf В основной /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 arguemnt, но это взлом.

Это работает, если я запускаю приложение из распакованного каталога. Как упаковать этот каталог после изменения разрешений chrome-sandbox ?

@ shrinidhi111 4755 можно сохранить в упакованном виде, по крайней мере, в случае пакетов pacman / deb. Пакеты также могут быть настроены на уровне специфического дистрибутива, например . Что касается корневого владельца, обычно, когда пакет устанавливается из репозитория в Linux, соответствующие файлы получают корневого владельца. В случае сборки AppImage я переупаковываю ее и жестко кодирую --no-sandbox arg во внутреннем скрипте AppRun, поскольку electronic-builder еще не делает этого из коробки. Пакет Snap формируется сборщиком электронов с жестко запрограммированным --no-sandbox arg (соответствующее исправление добавлено ~ 6 месяцев назад).

@ shrinidhi111 4755 можно сохранить в упакованном виде, по крайней мере, в случае пакетов pacman / dev. Пакеты также могут быть настроены на уровне специфического дистрибутива, например . Что касается корневого владельца, обычно, когда пакет устанавливается из репозитория в Linux, соответствующие файлы получают корневого владельца. В случае сборки AppImage я переупаковываю ее и жестко кодирую --no-sandbox arg во внутреннем скрипте AppRun, поскольку electronic-builder еще не делает этого из коробки. Пакет Snap формируется сборщиком электронов с жестко запрограммированным --no-sandbox arg (соответствующее исправление добавлено ~ 6 месяцев назад).

Создание файла снапа было отличной идеей и сэкономило мне много работы. Еще раз спасибо!

как это до сих пор не решено

на оснастке исправлено, у меня есть собственная сборка, которая работает с appimage. остальное не решено.

Этот поток невероятно длинный, и ошибка все еще возникает. Есть ли где-нибудь краткое изложение ситуации? Может быть, такое резюме могло быть связано с ошибкой.

Похоже, что https://github.com/electron/electron/issues/17972#issuecomment -495767027 и подобные предлагают, что достаточно, чтобы электрон работал легко и безопасно только в системах с корневым доступом. Может быть, было бы неплохо, если бы система обнаруживала неправильные настройки разрешений и предлагала разработчикам предупреждения, чтобы уменьшить количество пользователей, сталкивающихся с этой проблемой, но, возможно, это отдельная проблема. Кажется, также было бы неплохо, если бы был путь для пользователей без корневого доступа, чтобы легко использовать электрон, с четким пониманием того, что ненадежные ресурсы более опасны, чем обычно.

путь для пользователей без корневого доступа, чтобы легко использовать электрон

--no-sandbox Аргумент

vladimiry, я думал, например, о конечных пользователях без большого опыта работы с терминалами или о запущенных приложениях, которые обертывают электрон

Я думал, например, о конечных пользователях без большого опыта работы с терминалами или о запущенных приложениях, которые обертывают электронные

Вставьте этот --no-sandbox в ярлык приложения. Любой пакет Linux здесь будет работать нормально, независимо от системного значения kernel.unprivileged_userns_clone . Так что дело в упаковке приложения.

Это правда, если я разработчик, и сделаю подходящее предупреждение для своих конечных пользователей. Разве многие разработчики никогда не узнают об этой проблеме из-за того, что на них работает песочница пространства имен? Также вызывает беспокойство то, что существующие решения используются без уведомления вовлеченных лиц о том, что ненадежные ресурсы более опасны.

Это решение работает только в том случае, если вы получаете эту ошибку из-за WSL

Я столкнулся с этой проблемой при попытке использовать electron на WSL (WSL2 в моем случае).
Даже при использовании сервера X11 электрон не мог работать поверх X11.

Мне пришлось собрать электрон для Windows, даже если я запускаю его внутри WSL. После этого все работает как исключено
Самый простой способ сделать это:

• Удалить электрон npm uninstall electron
• Изменить платформу конфигурации npm 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 _поддерживает_ разрешения в системах на основе unix (или, по крайней мере, в тех вариантах Linux, которые я тестировал). См. Https://serverfault.com/a/585889/17620

Биты прав доступа хранятся в суффиксе заголовка файла центрального каталога zip. Поле суффикса externalFileAttributes может использоваться для хранения битов разрешений для каждой записи файла / каталога.

cc @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)]

но когда я ням устанавливаю оснастку после ， запуска от имени 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

надеюсь, что это поможет вам

не работает

@fabiospampinato ваша адаптация отключает песочницу для всех типов пакетов Linux, но, по крайней мере, пакеты DEB и Pacman хорошо работают с песочницей SUID (возможно, все пакеты, не похожие на контейнер), просто необходимо установить бит разрешения SUID на chrome-sandbox binary. Но не устанавливайте бит разрешения SUID для пакета Snap, поскольку Snap Store отклоняет такие типы пакетов. Поэтому я установил бит SUID для всех пакетов Linux, кроме пакетов Snap / AppImage, которые отключают песочницу и связанный код .

Привет @vladimiry
Мне не удалось получить доступ по ссылке, которую вы здесь разместили. Вы можете с этим помочь?
Вдобавок, смогли ли вы выяснить, как сделать --no-sandbox в сценарии after-pack electronic-builder?

Спасибо

@ tushar-compro, вот это https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. В основном я устанавливаю 4755 бит в сценарии after-pack для некоторых типов пакетов и все еще переупаковываю пакеты appimage + snap. Фактически, сборщик электронов уже встроил --no-sandbox arg в оснастку, но еще не в 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. Таким образом, последняя версия электронного сборщика должна упростить жизнь большинству разработчиков.

@vladimiry
Правильно ли я в понимании того, что вы установили 4755 бит для целей , отличных от appimage и оснастки.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Но проблема возникает при использовании установщика .appimage в дистрибутиве Debian.

Я что-то упустил?

Но проблема возникает при использовании установщика .appimage в дистрибутиве Debian.

Как я уже сказал, аппимаж по-прежнему требует особого обращения. Я переупаковываю его и вставляю --no-sandbox в сценарий ./AppRun . Найдите здесь ключевое слово DISABLE_SANDBOX_ARGS_LINE https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Но проблема возникает при использовании установщика .appimage в дистрибутиве Debian.

Как я уже сказал, аппимаж по-прежнему требует особого обращения. Я переупаковываю его и вставляю --no-sandbox в сценарий ./AppRun . Найдите здесь ключевое слово DISABLE_SANDBOX_ARGS_LINE https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

последний конструктор электронов автоматически заботится об аргументе no sanbox как в snap, так и в appimage.

@vladimiry
Итак, правильно ли я понимаю, что настройка 4755 бит, которую вы выполнили, предназначена для инсталляторов, отличных от appimage и snap. А для appimage вы установили без песочницы. Не могли бы вы подтвердить.

@ p3x-робот
да. ты частично прав.

1. В последнем электронном сборщике для оснастки не используется песочница, но НЕ для appimage. Однако они установили 4755 бит для appimage.
2. В моем проекте я использую электронную версию 20.xx. Обновление до 22.xx само по себе потребует усилий. Просто пытаюсь этого избежать, если возможно. Обновление до версии 22 будет крайней мерой.

последний конструктор электронов автоматически заботится об аргументе no sanbox как в snap, так и в appimage.

Пока не удалось найти в их коде специфичный для appimage фрагмент, подобный тому, который применяется для снимков (https://github.com/electron-userland/electron-builder/pull/4496 все еще открыт). В любом случае, в моем случае переупаковка все еще требуется, поскольку я добавил туда дополнительные аргументы, кроме связанных с sanbox.

Итак, правильно ли я понимаю, что настройка 4755 бит, которую вы выполнили, предназначена для инсталляторов, отличных от appimage и snap. А для appimage вы установили без песочницы. Не могли бы вы подтвердить.

Правильный. Но современный конструктор электронов устанавливает 4755 внутренне. Я проверяю, что он не настроен для snap / appimage, поскольку это было бы ошибкой. Например, если я правильно помню, привязка не будет запускаться с 4755 битами, установленными в двоичную систему электронов.

@vladimiry
Мне просто нужно установить без песочницы, так как мои образы приложений не работают в debian.

Думаю, в этом случае переупаковка мне не понадобится. Но мне не удалось найти подходящую документацию по сборщику электронов для этого. Или ты думаешь мне тоже нужна перепаковка?

Можете ли вы указать мне подходящую документацию, которая может помочь мне в этом.

Кроме того, я понимаю, что у меня есть оба варианта: установить бит 4755 или отключить песочницу.
Как вы думаете, какой из них лучше?

Кроме того, я понимаю, что у меня есть оба варианта: установить бит 4755 или отключить песочницу.

Если я правильно помню, настройка 4755 для appimage не решит проблему. Вам необходимо (одно из):

• запустите свой файл appimage с --no-sandbox command line arg
• иметь --no-sandbox встроенное в сценарий ./AppRun расположенный в вашем файле appimage (поэтому требуется переупаковка).

Можете ли вы указать мне подходящую документацию, которая может помочь мне в этом.

Сомневаюсь, что вы найдете подробную информацию о проблеме в какой-либо документации. Мне не известны какие-либо соответствующие документы.

Кроме того, я понимаю, что у меня есть оба варианта: установить бит 4755 или отключить песочницу.

Если я правильно помню, настройка 4755 для appimage не решит проблему. Вам необходимо (одно из):

• запустите его с --no-sandbox аргумент командной строки
• иметь --no-sandbox встроенное в сценарий ./AppRun расположенный в вашем файле appiamge (поэтому требуется переупаковка).

Можете ли вы указать мне подходящую документацию, которая может помочь мне в этом.

Сомневаюсь, что вы найдете подробную информацию о проблеме в какой-либо документации. Мне не известны какие-либо соответствующие документы.

Электронный конструктор в последнее время встраивает --no-sandbox в ./AppRun , который я раньше переупаковывал, но теперь он бесполезен, я просто использую собственный электронный конструктор.

@vladimiry
да. установка только 4755 не сработает. С 4755 нам нужно изменить владельца chrome-sandbox на root.
В любом случае, большое спасибо за вашу помощь. Тогда я попробую сослаться на ваш код и установить режим без песочницы.

@ p3x-робот
Не могли бы вы поделиться какой-нибудь ссылкой (репозиторий электронных построителей), где мы можем увидеть, как это делает код.

https://github.com/patrikx3/onenote

@vladimiry
да. установка только 4755 не сработает. С 4755 нам нужно изменить владельца chrome-sandbox на root.
В любом случае, большое спасибо за вашу помощь. Тогда я попробую сослаться на ваш код и установить режим без песочницы.

@ p3x-робот
Не могли бы вы поделиться какой-нибудь ссылкой (репозиторий электронных построителей), где мы можем увидеть, как это делает код.

https://github.com/patrikx3/onenote

Электронный конструктор в последнее время встраивает --no-sandbox в ./AppRun, который я раньше переупаковывал, но теперь он бесполезен, я просто использую собственный конструктор электронов.

Я только что протестировал его, используя последнюю версию электронного конструктора, и он не встраивает --no-sandbox в скрипт ./AppRun sh. Если вы запустите 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.

Электронный конструктор в последнее время встраивает --no-sandbox в ./AppRun, который я раньше переупаковывал, но теперь он бесполезен, я просто использую собственный конструктор электронов.

Я только что протестировал его, используя последнюю версию электронного конструктора, и он не встраивает --no-sandbox в скрипт ./AppRun sh. Если вы запустите 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 установок оснастки с последним сборщиком электронов. и, наконец, построитель электронов показывает, что он добавляет этот флаг ...

есть 10к снап

Мы говорим об appimage, а не о оснастке. Snap, конечно, имеет встроенный аргумент, как я упоминал выше, здесь https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/197ap.ts -L202.

есть 10к снап

Мы говорим об appimage, а не о оснастке. Snap, конечно, имеет встроенный аргумент, как я упоминал выше, здесь https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/197ap.ts -L202.

ты прав. Я почему-то думал, что это было сделано в appimage, я даже удалил код для переупаковки и добавил без песочницы, но я попробовал еще раз и вижу, что он отсутствует, поэтому я добавил свой откат моей сборки, нет работает. извините, в моем corifeus-builder вы можете увидеть, что я делаю: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Привет, @nornagon, учитывая, насколько распространена эта проблема, можно ли обновить официальное руководство по быстрому запуску в электронном виде, чтобы включить обходной путь, чтобы у новичков был положительный опыт?

Изменить: благодаря поддержке сообщества я открыл FR # 26478

@gabefair Это кажется разумным предложением. Хотели бы вы открыть PR?