Electron: تم العثور على الملف الثنائي لمساعد SUID sandbox ، ولكن لم يتم تكوينه بشكل صحيح

لسوء الحظ ، لا توجد طريقة يمكننا من خلالها تكوين هذا بشكل صحيح تلقائيًا ، لأن تعيين الأذونات المناسبة يتطلب امتيازات الجذر ولا نريد أن نطلب كلمة مرور جذر خلال 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

هل هناك حل بديل محتمل في هذه الأثناء حتى تتيح كل توزيعة لينكس هذه الميزات؟

kitingChris صندوق الحماية setuid هو الحل البديل. تحتاج فقط إلى التأكد من أنه عند تطوير / إصدار تطبيق إلكتروني ، تقوم البرامج النصية الخاصة بالتطوير / التعبئة بتعيين أذونات مساعد sandbox بشكل صحيح مثل nornagon المرتبط أعلاه.

هل هناك حل بديل محتمل في هذه الأثناء حتى تتيح كل توزيعة لينكس هذه الميزات؟

انظر الرسالة الأصلية:

إذا قمت بتشكيل الملف ثم chmod فإنه يعمل بشكل جيد

انظر أيضًا هنا https://github.com/electron/electron/issues/16631#issuecomment -476082063 لذلك لجعل suid sandbox يعمل ، عليك بشكل أساسي تعديل ثنائي chrome-sandbox بهذه الطريقة:

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

المشكلة أكثر خطورة على الرغم من أنه في حالة تشغيل حزم appimage / snap ، فأنا لم أكشف بعد عن حل بديل لهذه الحالات. إنه يعمل إذا تم تنفيذ appimage بـ --no-sandbox arguemnt ، لكن هذا اختراق.

تضمين التغريدة

لأن تعيين الأذونات المناسبة يتطلب امتيازات الجذر ولا نريد أن نطلب كلمة مرور جذر أثناء تثبيت npm.

لا يتطلب تنفيذ chmod 4755 node_modules/electron/dist/chrome-sandbox إذن الجذر وهذا يجب أن يكون كافيًا لتشغيل مثل هذا الأمر لتغليف التطبيق بحزم 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 كنت بحاجة إلى chmod أولاً ثم chmod. العكس لم ينجح.

burningTyger أنت على حق ، لقد غيرت الرسالة الأصلية للتو.

nornagon إذا كنا chmod 4755 out/Release/chrome-sandbox على CI ، فهل سيستمر هذا الإذن بمجرد أن نزيده zip أو هل يتعين علينا إجراء هذا التغيير في electron-download لإصلاح الإذن على DL؟

نفس الشيء هنا هو fonction جديد سيء لما يجب تغييره ... :(

MarshallOfSound لا يدعم zip الأذونات ، ولكن المشكلة في النهاية ليست إذن chmod ، بل المالك. المساعد setuid sandbox هو suid _to root_ ، لأنه يحتاج إلى أداء وظائف متاحة فقط للجذر. إذا كان من الممكن تعيين الأذونات المناسبة دون الحصول على امتيازات الجذر أولاً ، فستكون هذه ثغرة خطيرة جدًا في Linux. لحسن الحظ بالنسبة لنظام Linux ، ولسوء الحظ بالنسبة لنا ، لم يكن الأمر كذلك.

فيما يلي الخيارات كما أراها:

1. لا تغير شيئا في الإلكترون. نوصي المطورين بتمكين CLONE_USERNS بدون امتيازات على النواة الخاصة بهم للسماح بتشغيل وضع الحماية لمساحة الاسم بدلاً من وضع الحماية setuid.
2. قم بالتمهيد بدون وضع الحماية في حالة عدم توفر طريقة وضع الحماية _ فقط عند تشغيل تطبيق غير معبأ _. إذا كان Electron يقوم بتشغيل تطبيق مُجمّع ، فقم برفض التمهيد بدون وضع الحماية.
3. في جميع الحالات ، إذا لم تتوفر طريقة وضع الحماية ، فقم بالتمهيد بدون وضع الحماية واطبع تحذيرًا.
4. تعطيل وضع الحماية افتراضيًا على Linux.

أنا أميل نحو (2). سيسهل التطوير دون المساس بأمان التطبيق المنشور.

لست متأكدًا بعد مما يجب فعله بشأن snap / flatpak ، لأنني لست على دراية بأساليب عملها. من المحتمل أن يكون لديهم بالفعل وضع الحماية للتطبيق بشكل كافٍ بحيث يمكننا تعطيل وضع الحماية تمامًا في هذه الحالة ، كما نفعل عند إنشاء إصدار Mac App Store من Electron.

أما الآن فأنا أحب الخيار الأول أكثر.

1. التمهيد بدون وضع الحماية إذا لم تتوفر طريقة وضع الحماية إلا عند تشغيل تطبيق غير معبأ. إذا كان Electron يقوم بتشغيل تطبيق مُجمّع ، فقم برفض التمهيد بدون وضع الحماية.

مثل هذا السيناريو سيكون مضللاً إلى حد ما. قد يتم تشغيل تطبيق غير معبأ بنجاح دون وضع الحماية ، ولكن هناك احتمال ألا يعمل التطبيق المجمّع بنفس الطريقة مع وضع الحماية الممكّن. مثل ، على سبيل المثال ، الحالة عند الوصول إلى العملية الرئيسية من عملية العارض وليس من خلال واجهة remote . أو في حالة تغليف التطبيق بحزم AppImage / Snap / Flatpak.

1. في جميع الحالات ، إذا لم تتوفر طريقة وضع الحماية ، فقم بالتمهيد بدون وضع الحماية واطبع تحذيرًا.

لذلك ، قد يتم تنفيذ التطبيق المعبأ الذي تم تصميمه وتطويره ليكون وضع الحماية بدون وضع الحماية إذا لم يكن هناك وضع حماية متاح. هذا لا يبدو جيدًا بالنسبة لي.

1. تعطيل وضع الحماية افتراضيًا على Linux.

ماذا تعني بالتحديد؟ ما هي طريقة تمكين وضع الحماية على Linux بالطريقة التي يبدأ بها التطبيق أو يفشل إذا لم يكن وضع الحماية متاحًا (الوضع الحالي ، وضع الحماية القسري).

أحب أيضًا (1) ، ولكن للدفاع عن (2) قليلاً ، لن تتغير واجهة برمجة التطبيقات التي تتعرض للتطبيق عند تعطيل وضع الحماية. الشيء الوحيد الذي سنقوم بتعطيله هو وضع الحماية على مستوى نظام التشغيل. سنستمر في تحميل التطبيق بنفس الطريقة ، ولن يكون محميًا بواسطة نظام التشغيل.

سنستمر في تحميل التطبيق بنفس الطريقة ، ولن يكون محميًا بواسطة نظام التشغيل.

ثم يبدو ذلك جيدًا بالنسبة لي أيضًا. شكرا على الشرح.

لا أحب 2. ، لأن الأمان الاختياري يؤدي عمومًا إلى قيام الأشخاص بتعطيل الأمان.

عند الدخول في حذاء "المستخدم الغبي" الآن ، أفضل رؤية عمل الإلكترون افتراضيًا. إذا كان تدبيرًا أمنيًا مهمًا للغاية ، فأعطني تحذيرًا وشرحًا جيدًا لسبب حاجتي إلى القيام بعمل إضافي. إذا لم يكن الأمر بهذه الأهمية ، فلا تعطيني الطعم السيئ "إنه لا يعمل".

لهذا السبب ، أحب 1. (بقوة الإقلاع ، مثل الآن) أو 4.

: x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox يثير بعض العلامات الحمراء بالنسبة لي.

فقط لتوضيح ما يفعله: يقوم بتعيين بت SUID على chrome-sandbox ، مما يجعل _ أي مستخدم_ قادرًا على تنفيذ الملف _ as root_. هذا يعني أنه إذا كان هناك أي طريقة لاستخدام chrome-sandbox ضار ، أو إذا أصبحت المحتويات ضارة ، فقد يصبح أي مستخدم جذرًا. chrome-sandbox هدفًا مثيرًا للاهتمام للغاية للهجوم.

أوصي بشدة بعدم القيام بهذا الحل البديل على npm install ، لأنه سيتطلب sudo (يحتاج المستخدم إلى كتابة كلمة المرور) ، إنه غازي وقد لا نفهم العواقب الأمنية للقيام بذلك.

chown root: الجذر chrome-sandbox && chmod 4755 chrome-sandbox يثير بعض الأعلام الحمراء بالنسبة لي.

بالطبع ، هو كذلك. ولكن يمكنك تمكين وضع الحماية لمساحة اسم المستخدم كبديل sudo sysctl kernel.unprivileged_userns_clone=1 (يتم تمكينه افتراضيًا على Ubuntu ولكن ليس على Arch).

فقط لتوضيح ما يفعله: يقوم بتعيين بت SUID على chrome-sandbox ، مما يجعل _ أي مستخدم_ قادرًا على تنفيذ الملف _ as root_. هذا يعني أنه إذا كان هناك أي طريقة لاستخدام chrome-sandbox ضار ، أو إذا أصبحت المحتويات ضارة ، فقد يصبح أي مستخدم جذرًا. chrome-sandbox هدفًا مثيرًا للاهتمام للغاية للهجوم.

نعم ، ولكن أيضًا هذا الثنائي هو نفسه تمامًا الذي يأتي مع Chrome ، لذلك إذا كنت قلقًا بشأن هذا ، فمن المحتمل أن تقوم أيضًا بإلغاء تثبيت Chrome :)

هل هناك طريقة للتشغيل بدون وضع الحماية / التشغيل بدون "مساعد وضع الحماية"؟ حصلت على أول المستخدمين يشكون 😅
كنت أتوقع أن يؤدي هذا إلى تعطيل وضع الحماية ، ولكن ما زلت أتلقى الخطأ The SUID sandbox helper binary was found, but is not configured correctly .
أكره العودة إلى الإلكترون 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 ، قد ترغب في محاولة إضافة قابس كما هو موضح هنا . لست متأكدًا مما إذا كان ذلك سيساعدك لأنني لم أجربه بعد ، فسيكون رائعًا إذا قمت بذلك. في الوقت الحالي ، أفضل إطلاق التطبيق الذي كنت أقوم بإنشائه في الوضع المختلط : ابتسامة :. يتم استخدام Electron v5 لجميع الحزم باستثناء AppImage و Snap لأنه ليس من الواضح تمامًا بعد كيفية جعل هذه الحزم تعمل بشكل جيد مع تمكين وضع الحماية ، ولكن سيكون واضحًا في مرحلة ما.

إذا كان Snapcraft يحظر علامات suid ، فمن المحتمل أن يكون الخيار الوحيد هو تعطيل وضع الحماية لـ Electron بالكامل في Snapcraft والاعتماد على الحاوية التي يستخدمها Snapcraft. لست متأكدًا من أفضل طريقة للقيام بذلك - هل من الممكن تحديد علامات سطر أوامر إضافية عند التعبئة من خلال Snapcraft؟ إذا كان الأمر كذلك ، فيمكننا إضافة العلم --no-sandbox . إذا لم يكن الأمر كذلك ، فقد نحتاج إلى إضافة بعض آليات الكشف المحددة لاكتشاف التشغيل في Snapcraft / Flatpak وتعطيل وضع الحماية بناءً على هذا الاكتشاف.

بعض الوثائق المتعلقة بـ Snap https://docs.snapcraft.io/browser-support-interface

@ posix4e ، هل يمكنك إلقاء بعض الضوء على مشكلة تشغيل حزمة Snaped في وضع الحماية في كل من User Namespace و SUID sandbox / الوضع الاحتياطي؟ يبدو أنك حصلت على تجربة ذات صلة بتعديل التكوين المفاجئ لمتصفح Brave. سيسيflexiondotorg.

فقط لتوضيح ما يفعله: يقوم بتعيين بت SUID على chrome-sandbox ، مما يجعل _ أي مستخدم_ قادرًا على تنفيذ الملف _ as root_. هذا يعني أنه إذا كان هناك أي طريقة لاستخدام chrome-sandbox ضار ، أو إذا أصبحت المحتويات ضارة ، فقد يصبح أي مستخدم جذرًا. 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 على ملف مملوك من قبل مستخدم غير جذر.

يجب أن يكون إجراء تثبيت sudo chown root:root && sudo chmod 475 عند تثبيت npm غير وارد ، وسيحتاج npm إلى التشغيل كجذر لتعيين الأذونات. سيسمح نموذج الخطاف لـ npm لجميع الحزم المثبتة بتشغيل الخطافات الخاصة بهم كجذر أيضًا. مع وجود مئات الحزم والاعتمادات المتداخلة ، سيكون هذا خطيرًا جدًا.

عمل جذر sudo chown الجذر && sudo chmod 475 عند تثبيت npm غير وارد

لا يعتبر هذا خيارًا بقدر ما أفهمه.

أوافق على أن القيام بأي شيء يتطلب امتيازات الجذر أثناء تثبيت npm ليس بداية. وهذا هو السبب في أنني لم أدرجها كأحد الخيارات .

لما تستحقه ، تم إصدار electron-installer-debian 1.2.0 و electron-installer-redhat 1.1.0 و electron-installer-snap 3.2.0 مع تغييرات SUID sandbox. يجب أيضًا تحديث Electron Forge v5 و v6 beta بشكل انتقالي (عبر تحديثات الإصدار في النطاق ، استخدم npm update أو yarn upgrade مناسب).

فقط ربط الكود ذي الصلة من أجل الوضوح.

فقط للتوضيح ، بالنسبة لـ Snaps كان هناك المزيد لها (أي إضافة دعم وضع الحماية للمتصفح كما هو مذكور أعلاه). راجع تغييرات العلاقات العامة ذات الصلة للحصول على التفاصيل.

لقد قمت للتو بتشغيل هذا ، chown / chmod works ، لكن هذا ليس الإجراء الوحيد الضروري الذي يجب اتخاذه إذا كنت تعمل داخل صورة 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 sandbox. لست متأكدًا من سبب حدوث ذلك ، ولكن يمكنك فرض وضع الحماية suid بـ --disable-namespace-sandbox . إذا قمت بتشغيل docker بـ --privileged (أو --cap-add SYS_ADMIN ، أو ملف تعريف seccomp مخصص يسمح بـ CLONE_NEWUSER) ، فستتوفر مساحات الأسماء داخل sandbox ولن تكون هناك حاجة لـ setuid sandbox أو مساعدها القابل للتنفيذ .

مثل thomasnordquist ، انتهى بي الأمر الآن بتعطيل وضع الحماية لحزم Snap / AppImage باستخدام برنامج نصي للتحميل المسبق. تقوم بإنشاء برنامج نصي شبيه بالتحميل المسبق يسمى ثنائيًا أصليًا والذي يستخدم بعد ذلك لتحميل ثنائي الإلكترون الأصلي / المعاد تسميته باستخدام وسيطة --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 لدعم وضع الحماية ، فيرجى إبلاغي بذلك في أداة تعقب المشكلات الخاصة به.

إذا كان هناك خطأ ما في كيفية تنفيذ Electron-installer-snap لدعم وضع الحماية ، فيرجى إبلاغي بذلك في أداة تعقب المشكلات الخاصة به.

أود أيضًا أن أسمع شخصًا يؤكد أن التغيير كافٍ لمعالجة المشكلة مع حزم Snap. لذلك يتم الترحيب بكل من التقيمات الإيجابية / السلبية. انظر المعلومات ذات الصلة.

vladimiry لقد تقدمت واختبرت ذلك ولم ينجح.

أحتاج إلى حل لا يتم حله بخصوص تصحيحات نظام التشغيل أو sysctl أو إعادة التشغيل. أنا بحاجة إلى شيء يعمل الآن. سيفضل - no-sandbox.

سيكون من المفيد جدًا بالنسبة لي إذا كان بإمكان شخص ما توفير الحد الأدنى من تطبيق Electron الذي يمكنني استخدامه لإعادة إنتاج Snap المعبأ الذي لا يعمل. لقد استخدمت شوكة electron-quick-start لإنشاء Snap في CircleCI وقمت بتثبيته على جهاز الكمبيوتر المحمول (Debian Stretch) للتحقق من أن التغييرات التي أجريتها قد أنشأت على الأقل تطبيق Electron يعمل.

لا تساعدني عبارة "لم تنجح" في تحديد ما يمكنني فعله بعملة electron-installer-snap حتى أتمكن من حزمها بشكل صحيح للآخرين.

burtonator ، شكرًا لاختبار الأشياء. بقدر ما أعلم ، فإن الحزم في Snap / AppImage build driver-like bash / sh script الذي يبدأ الثنائي / الإلكترون الأصلي باستخدام وسيطة cmd --no-sandbox هو الحل الوحيد الذي تم التحقق منه في الوقت الحالي.

malept قبل اختبار الأشياء ، هناك حاجة لتعطيل ميزة User Namespace OS من خلال تنفيذ sudo sysctl kernel.unprivileged_userns_clone=0 .

vladimiry نعم ، جهاز الكمبيوتر المحمول الخاص بي به بالفعل إعداد المستخدم هذا.

إذا كان هناك من يبحث عن حل لهذه المغادرةthomasnordquist الصورة حل بلدي أو التكيف من ذلك، فإنها تعمل عن طريق تعطيل رمل في لينكس.

fabiospampinato يعمل تكيفك على تعطيل وضع الحماية لجميع أنواع حزم Linux ولكن على الأقل حزم DEB و Pacman تعمل بشكل جيد مع SUID sandbox (ربما جميع الحزم التي لا تشبه الحاوية) ، هناك حاجة فقط لتعيين بت إذن SUID إلى chrome-sandbox ثنائي. لكن لا تقم بتعيين بت إذن SUID لحزمة Snap لأن Snap Store يرفض مثل هذه الأنواع من الحزم. لذلك قمت بتعيين SUID bit لجميع حزم Linux ، وتتوقع حزم Snap / AppImage التي تحصل على وضع الحماية المعطل ، والشفرة ذات الصلة .

CONFIG_USER_NS = y تُمكّن ميزة مساحات أسماء المستخدمين ، لكنها لا تزال مقيدة بالمستخدمين المتميزين افتراضيًا. يشير هذا إلى sysctl kernel.unprivileged_userns_clone = 1

أؤكد أن تنفيذ sudo sysctl kernel.unprivileged_userns_clone=1 هو حل آخر ، تعليق ذي صلة.

شكرا يا صديقي ، العمل من أجلي! تضمين التغريدة

هل تعرفون يا رفاق ما إذا كان يعمل الآن مع 5.0.2؟

@ p3x-robot لم يرد ذكر لهذه المشكلة في سجل التغيير. فقط تحقق للتأكد وما زال الخطأ موجودًا بالنسبة لي.

rybaczewa شكرًا على الرد ، أظل على الإصدار 4 أيضًا ، لأنها مشكلة كبيرة ، لا يمكنني الانتظار حتى يعمل الإصدار 5 ، ciao

غير قادر على الانتظار حتى يعمل v5

v5 يعمل

لتوضيح الأمر للأشخاص الموجودين في هذا الموضوع ، @ p3x-robotrybaczewa ، تُترك هذه المشكلة مفتوحة للأغراض الإعلامية / النهائية. يعمل الإلكترون نفسه كما هو متوقع ولا يوجد شيء هنا "لإصلاحه".

إذا كنت ترى رسالة السجل هذه ، فأنت بحاجة إما إلى تشغيل sudo sysctl kernel.unprivileged_userns_clone=1 أو إعطاء chrome_sandbox الثنائي الأذونات الصحيحة كما هو موضح في رسالة الخطأ.

vladimiryMarshallOfSound لماذا أنت تقول هو ثابت هذا؟ في 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 support كما هو موضح أعلاه يتعلق بكيفية إجراء الخاطف. 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 ، فأنت تضيفه على النحو التالي:

لكم جميعًا ، إذا كنتم ترغبون في تفعيله ، فقد أنشأت مساعدًا:

تم بالفعل ذكر هذا الحل عدة مرات في مناقشة هذه القضية ، ولهذا السبب كتبت قبل أن يعمل الإلكترون v5.

vladimiry شكرًا ، فاتني هذا الحل ، لقد أضفت للتو حلًا

المشكلة الوحيدة هي أنه عندما أقوم بهذا بعد اختراق الحزمة ، فإنه لا يستخدم على اللوحة أيقونة من الإلكترون ، ولكنه يولد رمزًا ثانيًا ، هل يمكن حل ذلك يا رفاق؟ أعتقد أن علم no-sandbox يفعل ذلك. أي واحد؟

يحدث فقط مع --no-sandbox :

fabiospampinato يعمل تكيفك على تعطيل وضع الحماية لجميع أنواع حزم Linux ولكن على الأقل حزم DEB و Pacman تعمل بشكل جيد مع SUID sandbox (ربما جميع الحزم التي لا تشبه الحاوية) ، هناك حاجة فقط لتعيين بت إذن SUID إلى chrome-sandbox ثنائي. لكن لا تقم بتعيين بت إذن SUID لحزمة Snap لأن Snap Store يرفض مثل هذه الأنواع من الحزم. لذلك قمت بتعيين SUID bit لجميع حزم 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 .

@ vladimiry شكرًا جزيلاً ، لأنه مثير للاهتمام لـ afterAllArtifactBuild ، سأحاول تغيير command.sh دون تفريغ ، ولكنه غدًا ، شكرًا مرة أخرى!

واحد مثير للاهتمام لما بعد AllArtifactBuild

@ p3x-robot afterAllArtifactBuild الخطاف في الواقع لا يتم تشغيله كما توقعت ، ولكن من السهل جدًا تشغيل Snap أو إنشاء أي نوع حزمة آخر برمجيًا. انظر هنا نموذج التعليمات البرمجية. snapFile هو ملف النتيجة هنا ، لذا يمكنك فك ضغط / unsquashfs بعد ذلك ، قم بتطبيق التغييرات المطلوبة واستعادة حزم / snapcraft pack . في مثال الكود ، أحزم قواميس Hunspell في مجلد Snap ./usr/share/hunspell .

vladimiry أنا فقط استخدم Electron v4 ، لأن هذا يعمل. أعتقد أن شخصًا ما سيصلح هذا.

@ p3x-robot ما زلت أميل إلى الاعتقاد بأن عليك الاعتراف بأنه لا يوجد شيء لإصلاحه.

vladimiry لا يوجد شيء لإصلاحه بالتأكيد. :)

أي شخص يعرف ما إذا كان Electron v5.0.2 يعمل مع قضية sandbox؟

إنه ، مثل الإصدار 5.0.0: ابتسامة:

آمل ألا يكون هذا خارج الموضوع ولكن بالنسبة إلى AppImages على دبيان (9) ، فقد تلقيت الخطأ:

The setuid sandbox is not running as root. 

صححني إذا كنت مخطئًا لكنني أفهم (بشكل أساسي من هذه المناقشة) أن هذا ناتج عن ميزة مساحات أسماء المستخدمين المعطلة التي يتم تعطيلها افتراضيًا في دبيان.

إذن فيما يتعلق بهذا الاقتراح:

1. لا تغير شيئا في الإلكترون. نوصي المطورين بتمكين CLONE_USERNS بدون امتيازات على النواة الخاصة بهم للسماح بتشغيل وضع الحماية لمساحة الاسم بدلاً من وضع الحماية setuid.

أرغب في عرض رسالة للمستخدمين تفيد بأنه لا يعمل إلا عند تمكين ميزة مساحات أسماء المستخدمين (ربما مع تلميح حول كيفية القيام بذلك) واقترح استخدام حزمة .deb كبديل.

كيف يمكنني تنفيذ مثل هذه الرسالة قبل ظهور الخطأ؟ هل توجد طريقة لإضافة برنامج نصي مخصص مسبقًا إلى AppRun في AppImage دون فك حزمه وإعادة حزمه؟

هل توجد طريقة لإضافة برنامج نصي مخصص مسبقًا إلى AppRun في AppImage دون فك حزمه وإعادة حزمه؟

gcascio كانت هناك رسائل في سلسلة الرسائل حول استخدام برنامج نصي شبيه بمحمل sh والذي يمكن حقنه بواسطة البرنامج النصي

شكرا لردك. لكنني أعتقد أن AppRun الذي تم إنشاؤه غير متاح عندما يتم استدعاء afterpack أو عندما أكون مخطئًا ، على الأقل لا يمكنني العثور عليه في appOutDir ؟

أعتقد أن AppRun الذي تم إنشاؤه غير متاح عند استدعاء afterpack

كنت أكتب عن استخدام برنامج نصي يشبه أداة التحميل ولكن ليس عن تصحيح برنامج AppRun النصي. إذا كنت تريد تصحيح البرنامج النصي AppRun ، فيبدو أنه لا توجد طريقة للقيام بذلك دون إعادة تجميعه.

حسنًا ، لقد أسأت الفهم. قد أذهب مع إعادة التعبئة ثم شكرا.

قد أذهب مع إعادة التعبئة ثم شكرا.

gcascio في حال كنت بحاجة إلى قالب .

نفس الخطأ "تم العثور على ملف مساعد SUID sandbox" ولكن في ملف snap بعد التثبيت
كيف يمكن اصلاح هذا

vladimiry أنا أعمل في IDE Docker عبر الإنترنت يسمى http://gitpod.io يشغل حاوية دبيان. لا يمكنني إصلاح مشكلة chrome-sandbox حيث لا يمكنني الوصول إلى sudo. النغمة العامة هنا هي أن هذه مشكلة في Chrome وليست مشكلة إلكترون ، ولكن إذا تمكنت Electron من حل المشكلة ، فلن يكون ذلك شيئًا جيدًا؟

من هذا الموقع https://www.gitpod.io/blog/gitpodify/ لقد رأيت حلاً لاستخدام Puppeteer في الحاوية.

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

هل يمكن للإلكترون تجربة بعض التعليمات البرمجية من هذا القبيل في حالة حدوث خطأ في وضع الحماية ، قبل قتل العملية؟ أم أن هذا شيء يمكنني استدعاؤه باستخدام ملف باش؟

هل يمكن للإلكترون تجربة بعض التعليمات البرمجية من هذا القبيل في حالة حدوث خطأ في وضع الحماية ، قبل قتل العملية؟ أم أن هذا شيء يمكنني استدعاؤه باستخدام ملف باش؟

نعم ، من المفترض أن يعمل تمرير الوسيطة --no-sandbox إلى ثنائي تطبيقات الإلكترون بشكل عام على حل هذه المشكلة.

اعتمادًا على حزمة التثبيت ، يمكنك تعيين بت إذن SUID (4755) إلى chrome-sandbox binary (للحزم مثل deb ، pacman ، إلخ) أو الكود الثابت --no-sandbox وسيطة إلى محمل sh / bash script (لحزم مثل Snap و AppImage). هذا ما أفعله حاليًا ولذا ليست هناك حاجة لفعل أي شيء لمستخدمي التطبيق (لا يلزم الوصول إلى sudo).

يأتي إصدار منشئ الإلكترون الأخير بالفعل مع تشفير ثابت للوسيطة --no-sandbox ولكن فقط لحزمة Snap.

بفضل vladimiry electron - يبدو أن

هناك أحدث صانعي الإلكترون ، ولكن AppImage لا يزال غير ثابت ، أليس كذلك؟

هل يعمل الإلكترون 6 على إصلاح خطأ الحماية؟ ما زلت في الإصدار 4 لأنني لا أستطيع إصلاح ذلك ، لا 5 أو 6.

هذا هو الوضع:

• قام Electron v5 بتمكين وضع الحماية المختلط (على سبيل المثال ، يتم وضع الحماية لبعض العمليات والبعض الآخر ليس كذلك) على Linux. لا يغير هذا ما إذا كانت عمليات العارض الخاصة بك في وضع الحماية افتراضيًا ، ولكن هذا يعني أن عملية GPU أصبحت الآن في وضع الحماية.
• يستخدم وضع الحماية لـ Chromium على Linux ميزة نظام تشغيل تسمى CLONE_NEWUSER . تم إنشاء بعض النوى باستخدام هذه الميزة التي تقتصر على المستخدمين المميزين بدافع من الحذر الشديد. يمكنك قراءة المزيد عنها هنا [lwn ، 2016].
• عندما لا يتوفر CLONE_NEWUSER ، يعود Chromium إلى استخدام آلية آلية مختلفة لوضع الحماية تتطلب ثنائيًا مساعدًا تم ضبطه على الجذر. إذا لم يكن هذا البرنامج الثنائي موجودًا أو لم يكن لديه الأذونات الصحيحة ( 4755 _ ويملكه root_) ، فسيفشل التمهيد.
• يجب أن يتم تعيين الأذونات الثنائية المساعدة بواسطة مستخدم ذي امتياز (مثل الجذر). لم نضع هذه الأذونات على npm install ، لأننا لا نريد أن نطلب الوصول إلى الجذر أثناء npm install .
• تتضمن حزم إصدار Electron v5 الثنائي المساعد ، ولكن الأمر متروك لأدوات التعبئة والتوزيع المختلفة لضمان حصولها على الأذونات والملكية الصحيحة.

هناك نوعان من الحلول:

1. قم بتمكين الوصول غير المتميز إلى CLONE_NEWUSER في النواة الخاصة بك. تدعم بعض النوى تغيير هذا بـ sysctl kernel.unprivileged_userns_clone=1 .
2. قم بتعطيل وضع الحماية تمامًا من خلال الإطلاق بـ --no-sandbox . إن إضافة هذه الوسيطة من JS غير كافية للأسف ، حيث يتم تشغيل عملية GPU قبل تشغيل العملية الرئيسية JS.

لن ندعم التعطيل التلقائي لوضع الحماية في Electron عند اكتشاف هذه الشروط. يجب عليك التأكد من أن الحزم الموزعة الخاصة بك لتعيين الأذونات المناسبة. تدعم معظم الأدوات (على الأقل مُنشئ الإلكترون ، ومُثبت الإلكترون ، ومُثبت الإلكترون ، وديبيان ، ومُثبت الإلكترون) هذا تلقائيًا ولا تتطلب أي تكوين من المطور. إذا كنت تستخدم أداة مختلفة لا تدعم ذلك ، فالرجاء طرح مشكلة على تلك الأداة والارتباط بهذا التعليق.

أقوم بإغلاق هذه المشكلة لأنه ، كما هو مذكور في الفقرة السابقة ، لن نغير الشرط الذي يقضي بأن يتطلب الإلكترون في الإنتاج الوصول إلى وضع الحماية الفعال ما لم يتم توجيه تعليمات صريحة بخلاف ذلك. ومع ذلك ، ولتسهيل التطوير ، فتحت رقم 19550 لتتبع خيار التدهور تلقائيًا إلى الوضع بدون وضع الحماية عندما يتم تثبيت Electron عبر npm install ، وليس عبر حزمة موزعة.

@ p3x-robot ، يمكنك العثور على مثال بسيط للحل البديل 2. مذكور بواسطة nornagon هنا وهو مستوحى منvladimiry

gcascio لكن يمكنني إزالة الاختراق الخاطف أليس كذلك؟ بما أن الخاطف يتم إجراؤه في منشئ الإلكترون ، هل يمكنك التأكيد؟

gcascio إنه يعمل ، شكرًا جزيلاً! إنها تعمل!

gcascio no workie ، فإنه يولد رمزين ، لذلك عدت إلى الإلكترون v4.2.8 ... :(

@ p3x-robot شكرًا على التعليقات. في حال كنت مهتمًا ، فقد قمت بإنشاء مشكلة وسوف يتم اجتياحها بمجرد أن أجد بعض الوقت.

nornagon لذلك لا يمكننا حتى تشغيل Electron 6 على دبيان ولا توجد طريقة لإعطاء عمليات جذر عملية الكروم. الحلول المقدمة ليست كافية من منظور المستخدم.

هناك نوعان من الحلول:
قم بتمكين الوصول غير المتميز إلى CLONE_NEWUSER في kernel الخاص بك. تدعم بعض النوى تغيير هذا باستخدام sysctl kernel.unprivileged_userns_clone = 1.

لا توجد أي طريقة للعبث بجهاز كمبيوتر العملاء هو السبيل للقيام بذلك.

قم بتعطيل وضع الحماية تمامًا عن طريق الإطلاق باستخدام - no-sandbox. إن إضافة هذه الوسيطة من JS غير كافية للأسف ، حيث يتم تشغيل عملية GPU قبل تشغيل العملية الرئيسية JS.

ماذا عن إضافة علامة --sandbox وإيقاف تشغيل ميزة sandbox افتراضيًا؟ هذا له فائدة في عدم إفساد 99٪ من الأشخاص الذين يستخدمون الإلكترون.

الحلول المقدمة ليست كافية من منظور المستخدم.

يمكن أيضًا اعتبار استخدام البرنامج النصي / البرنامج الذي يشبه أداة التحميل والذي سيضيف --no-sandbox arg كحل بديل ، لذلك لا يلزم اتخاذ إجراءات من جانب المستخدم النهائي. إلى جانب هذا المحمل يمكنه اختبار دعم user namespace أولاً وإضافة --no-sandbox فقط إذا لزم الأمر.

pronebird يعتبر إعطاء جذر setuid الثنائي 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 داخل الحاوية.

تضمين التغريدة

إن إعطاء جذر setuid الثنائي chrome-sandbox أقل خطورة بكثير من تشغيل الإلكترون بدون وضع الحماية. ضع في اعتبارك: أنت الشخص الذي يقوم بشحن ثنائيات Electron ، لذلك يمكنك أن تشعر بالثقة في أنك تقوم بشحن رمز موثوق (على سبيل المثال من خلال التوقيع عليه). ومع ذلك ، إذا كان من الممكن إقناع تطبيقك بتحميل كود غير موثوق به (ربما عن قصد ، على سبيل المثال ، بالانتقال إلى عنوان URL على الويب) ، فحينئذٍ سينفذ التطبيق هذا الرمز بسعادة بإذن من المستخدم ، دون أي نوع من الحماية. سأكون أكثر قلقًا بشأن الدفاع ضد الهجمات التي تركز على تشغيل JS غير موثوق به في عملية غير محمية في تطبيقك أكثر مما سأكون قلقًا بشأن الهجمات التي تنطوي على استغلال خطأ في نفس نظام الحماية الذي يستخدمه Chrome. (وأتوقع أن يتم إصلاح هذا الأخير بسرعة كبيرة إذا تم اكتشافه).

بالتأكيد ، ولكن تشغيل وضع الحماية لا معنى له إذا كان لديك تطبيق لا يقوم بتحميل أي محتوى عن بعد. أعتقد أن هذا يجب أن يكون هو الحال بالنسبة لـ Electron - لبناء تطبيقات سطح المكتب باستخدام مكدس الويب ، ربما يتم تحميل JSON من الويب ، ولكن ليس مثل عرض صفحات الويب فقط مثل عدم وجود Safari لذلك. لقد تجاوزنا الأوقات التي اعتاد فيها الناس على التفاف المواقع في فجوة الهاتف ، أليس كذلك؟

أعتقد أن النفقات العامة أكثر من اللازم. لقد أضفت برنامج bootstrap اليوم إلى تطبيقنا ، وأزلت chrome-sandbox ثنائي من التوزيع ، والذي كان 5 ميغا أخرى. لسوء الحظ ، electron-builder لا يدعم أيًا من هذا ، لذلك كان علينا إضافة خطاف والقيام بذلك بأنفسنا.

إذا كنت تريد تدقيق رمز ثنائي chrome-sandbox بنفسك ، فيمكنك البدء من هنا: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. ج # 424

شكرا. يعتمد الأمر حقًا على نموذج التهديد ، ولا توجد طريقة لتشغيل أي شيء من Google بأذونات الجذر.

يمكن أن يكون آمنًا تمامًا ، ولكن سيكون من الصعب حقًا التحقق من أن جميع المصادر سليمة نظرًا لأن عمليات إنشاء الإلكترونات يتم شحنها عبر npm. سيتعين علينا إعداد خادم إنشاء مخصص للإلكترون ومراجعة المصادر بأنفسنا. سيكون هذا جهدًا هائلاً وأنا أفضل تجنبه.

pronebird لن أشارك كثيرًا في مناقشة وضع الحماية ولكن موقفي هنا هو أنه يجب تمكين وضع الحماية افتراضيًا كما نفعل حاليًا.

يمكن أن يكون آمنًا تمامًا ، ولكن سيكون من الصعب حقًا التحقق من أن جميع المصادر سليمة حيث يتم شحن الإنشاءات الإلكترونية عبر npm

هذا غير صحيح من حيث الأساس ، لا يتم شحن تراكيب الإلكترونات عبر npm. الحزمة electron على npm هي في الواقع حوالي ملفين و 40 سطرًا من JS. يتم تسليم تصميمات Electron الفعلية عبر S3 ولديها مجاميع اختبارية أيضًا على S3 حتى يتمكن الأشخاص من التحقق من أن البنية التي يقومون بتنزيلها هي في الواقع البنية التي تم شحنها Electron.

تضمين التغريدة

هذا غير صحيح من حيث الأساس ، لا يتم شحن تراكيب الإلكترونات عبر npm. حزمة الإلكترون على npm هي في الواقع حوالي 2 ملف و 40 سطرًا من JS. يتم تسليم تصميمات Electron الفعلية عبر S3 ولديها مجاميع اختبارية أيضًا على S3 حتى يتمكن الأشخاص من التحقق من أن البنية التي يقومون بتنزيلها هي في الواقع البنية التي تم شحنها Electron.

ما قصدته هو أنه يتم تنزيل الإصدارات أثناء مرحلة npm install . لم أقصد أنهم مستضافون فعليًا على npm. فليكن يتم استضافتها على S3. أثبت أنني مخطئ ، لكنني أراهن أن المجاميع الاختبارية مستضافة على نفس S3 ، مما يقلل من درجة الأمان لهذا النظام ، إنها ساق واحدة فقط. ولكن هذا ليس نقطة. تخيل السيناريو الذي يتم فيه العبث بالبنيات الخاصة بك وتحديث المجاميع الاختبارية وفقًا لذلك. الآن لدينا مشكلة. هذا مجرد التحكم في المخاطر والأضرار من جانبي. لا يوجد جذر = مخاطر أقل لحدوث شيء سيء حقًا.

pronebird chrome-sandbox binary بالتأكيد لا يجب أن يكون 5

أنت مرحب بك بالتأكيد لاختيار تعطيل وضع الحماية لحالة الاستخدام الخاصة بك. من المؤسف أن بنية Chromium تجعلها تضطر إلى تمرير --no-sandbox في سطر الأوامر مباشرة بدلاً من استدعاء app.commandLine.appendSwitch ؛ سيكون تعطيل Sandbox بشكل مثالي ممكنًا دون الحاجة إلى برنامج نصي مُجمّع. نأمل مع # 20049 تحسين الاهتمام بإزالة الملف الثنائي ، نظرًا لأن 200 كيلو بايت إضافي أكثر منطقية للعيش مع أكثر من 5 ميغا بايت.

هل هناك خيار لاستخدام نظام ثنائي؟ لدي تحفظات حول إعطاء بت جذر suid لأي شيء في مجلد node_modules / الخاص بي. شكرا.

gardner ، يمكنك اجتياز --no-sandbox arg وهو نوع من الحل السهل عندما تكون في وضع dev.

تحول VSCode مؤخرًا إلى Electron 6 والآن نحصل على تقارير تفيد بأن VSCode لم يعد يعمل إلا إذا تم توفير خيار --no-sandbox . ما هو الطريق إلى الأمام هنا؟ المراجع: https://github.com/microsoft/vscode/issues/81056

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. هل هناك التزام أدى إلى إصلاح؟

لماذا تم إغلاق القضية؟ يبدو أنه لا يوجد إصلاح متاح لأنه لا يزال قائما حتى في الإصدار 7.0.0

لأن الأمر يتعلق بتعبئة تطبيقك ولكن ليس مشكلة الكترون.

آه ، حسنًا. لكن كيف أبدأ في إصلاح هذا ، رغم ذلك؟ هل هناك أي طريقة لا يضطر فيها المستخدم النهائي إلى القيام بأي عمل إضافي؟

هل هناك أي طريقة لا يضطر فيها المستخدم النهائي إلى القيام بأي عمل إضافي؟

نعم ، هناك طريقة ، تمت مناقشتها من قبل.

sudo sysctl kernel.unprivileged_userns_clone = 1

هناك مشكلة مع مستخدمي WSL (هناك الكثير ممن يستخدمون WSL) ولا يستخدم WSL 1 نواة لينوكس فعلية ... سيتعين علينا انتظار إصدار 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 وتشغيله ببساطة دون الوصول إلى الجذر؟ عذرًا ، لم أكن أدرك أن هذا كان خاصًا بدبيان ، وأن نواة الخط الرئيسي لا تدعم حتى تعطيل مساحات الأسماء غير المتميزة.

عفوا جرأتي ولكن هذا جنون تماما. يعرض Electron واجهة برمجة تطبيقات Node.js حتى في عمليات العارض. يعد استخدام / تمكين وضع الحماية لـ Chromium في تطبيق Electron أمرًا لا طائل منه تمامًا ، وكما ترون جميعًا من تقارير الأخطاء حول GitHub التي تشير إلى هذه المشكلة ، فإنها تؤدي أيضًا إلى نتائج عكسية للغاية. يرجى تعطيله إذا كان ذلك ممكنا.

يعرض Electron واجهة برمجة تطبيقات Node.js حتى في عمليات العارض.

الخيار nodeIntegration معطل افتراضيًا منذ الإصدار الخامس.

عذرًا ، لم أكن أدرك أن هذا كان خاصًا بدبيان ، وأن نواة الخط الرئيسي لا تدعم حتى تعطيل مساحات الأسماء غير المتميزة.

لذا عند تشغيل دبيان ، يبدو أنني محظوظ لأن لدي وصولاً إلى الجذر على جهازي. لكنني على صواب في أن هذه الميزة كما هي ستمنع المستخدمين من تشغيل تطبيقات الإلكترون (مثل AppImage أم لا) بدونها

أ) وجود sudo ، أو
ب) القدرة على إقناع شخص لديه sudo لتمكين مساحات الأسماء غير المتحضرة؟

@ black-puppydog حسنًا ، إذا كانوا ينشئون التطبيق من المصدر ، فيمكنهم تحرير نص البداية لتمرير الوسيطة --no-sandbox إلى الإلكترون. يجب أن يكون من الممكن تعديل AppImage بنفس التأثير (عن طريق تفريغه وإعادة حزمه) ، لكنني لم أجرب ذلك بنفسي. كما أنه ليس من المستحيل أن يقوم بعض منشئي AppImage بتضمين هذه العلامة في بنياتهم ، وفي هذه الحالة ستعمل تلك الصور المحددة فقط.

خلاف ذلك ، أعتقد أنك على صواب. لاحظ أن kernel الرئيسي يحتوي دائمًا على مساحات أسماء غير مميزة ممكَّنة ، ولا يوفر طريقة لتعطيلها. لهذا السبب هذه ليست سوى مشكلة على دبيان.

@ black-puppydog على ما أذكر ، يطالبك برنامج التثبيت بكلمة مرور جذر عند تثبيت Debian لأول مرة على جهازك. لكن نعم ، في Debian (أو أي نظام آخر يستخدم تصحيح النواة الخاص بـ Debian) ، تحتاج إما إلى الوصول إلى الجذر (عبر sudo أو غير ذلك) ، أو تشغيل تطبيقات Electron بـ --no-sandbox .

ndorf في نظام Linux الرئيسي ، يمكن تعطيل مساحات أسماء المستخدمين من خلال عدم تجميعها في الميزة ، ولكن لا يمكن تمكينها / تعطيلها في وقت التشغيل أو تقييدها على العمليات المميزة فقط. تصحح دبيان نواتها بحيث تقتصر مساحات أسماء المستخدمين على العمليات المميزة افتراضيًا ، ولكن يمكن تمكينها لجميع العمليات ذات الإعداد الأقل من /proc/sys .

السبب وراء تقييد دبيان لذلك هو أن مساحات أسماء المستخدمين غير المتميزة تشكل خطرًا أمنيًا خطيرًا مع تاريخ طويل من الثغرات الأمنية. تسمح مساحات أسماء المستخدمين غير المتميزة بالوصول إلى العديد من وظائف kernel (UID 0 ، القدرات ، تحميل نظام الملفات ، إنشاء inode للجهاز ، إلخ) التي كانت مقصورة على العمليات المميزة فقط لفترة طويلة جدًا. أي رمز نواة الاعتماد على افتراض أن عمليات المحرومين لن تكون قادرة على القيام بهذه الأشياء عرضة الآن أن عمليات المحرومة وفجأة قادرا على القيام بهذه الأشياء.

هل هناك حل بديل محتمل في هذه الأثناء حتى تتيح كل توزيعة لينكس هذه الميزات؟

انظر الرسالة الأصلية:

إذا قمت بتشكيل الملف ثم chmod فإنه يعمل بشكل جيد

انظر أيضًا هنا # 16631 (تعليق) لذلك لجعل suid sandbox يعمل ، عليك بشكل أساسي تعديل ثنائي 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 الداخلي حيث أن منشئ الإلكترون لا يفعل ذلك بعد من الصندوق. يتم تشكيل حزمة Snap بواسطة منشئ الإلكترون مع --no-sandbox arg (تمت إضافة الإصلاح ذي الصلة منذ حوالي 6 أشهر).

@ shrinidhi111 4755 يمكن الاحتفاظ بها عند تعبئتها ، على الأقل في حالة حزم pacman / dev. يمكن أيضًا تعديل الحزم على مستوى التوزيع المحدد ، على سبيل المثال . بالنسبة لمالك الجذر ، عادةً عندما يتم تثبيت الحزمة من الريبو على Linux ، تحصل الملفات ذات الصلة على مالك الجذر. في حالة إنشاء AppImage ، أعيد تجميعه وأعيد تجميعه والرمز الثابت --no-sandbox arg في البرنامج النصي AppRun الداخلي حيث أن منشئ الإلكترون لا يفعل ذلك بعد من الصندوق. يتم تشكيل حزمة Snap بواسطة منشئ الإلكترون مع --no-sandbox arg (تمت إضافة الإصلاح ذي الصلة منذ حوالي 6 أشهر).

كان إنشاء ملف snap فكرة ممتازة ووفّر لي الكثير من العمل. شكرا لك مرة أخرى!

كيف لا يزال هذا دون حل

على snap تم إصلاحه ، لدي تصميم خاص بي يعمل مع appimage. لبقية لم تحل.

هذا الخيط طويل بشكل لا يصدق ولا يزال الخطأ موجودًا. هل يوجد ملخص للوضع في أي مكان؟ ربما يمكن ربط هذا الملخص بالخطأ.

يبدو أن https://github.com/electron/electron/issues/17972#issuecomment -495767027 وما شابه يقترح أنه يكفي أن يكون لديك وظيفة الإلكترون بسهولة وأمان فقط على الأنظمة ذات الوصول إلى الجذر. ربما يكون من الجيد أن يكتشف النظام إعدادات الأذونات غير الصحيحة ويقدم تحذيرات للمطورين لتقليل المستخدمين الذين يواجهون هذه المشكلة ، ولكن ربما تكون هذه مشكلة منفصلة. يبدو أيضًا أنه سيكون من الجيد إذا كان هناك مسار للمستخدمين الذين ليس لديهم وصول إلى الجذر لاستخدام الإلكترون بسهولة ، مع فهم واضح أن الموارد غير الموثوق بها أكثر خطورة من المعتاد.

المسار للمستخدمين الذين ليس لديهم وصول إلى الجذر لاستخدام الإلكترون بسهولة

--no-sandbox CLI وسيطة.

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
• تثبيت electron 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 sandbox هو suid _to root_ ، لأنه يحتاج إلى أداء وظائف متاحة فقط للجذر. إذا كان من الممكن تعيين الأذونات المناسبة دون الحصول على امتيازات الجذر أولاً ، فستكون هذه ثغرة خطيرة جدًا في Linux. لحسن الحظ بالنسبة لنظام Linux ، ولسوء الحظ بالنسبة لنا ، لم يكن الأمر كذلك.

zip _does_ يدعم الأذونات على الأنظمة المستندة إلى unix (أو على الأقل على متغيرات Linux التي اختبرتها). راجع https://serverfault.com/a/585889/17620

يتم تخزين بتات الإذن في لاحقة رأس ملف الدليل المركزي في zip. يمكن استخدام الحقل externalFileAttributes بالملحق لتخزين وحدات بت الأذونات لكل إدخال ملف / دليل.

تضمين التغريدة

لدي نفس المشكلة !

[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)] يعمل كجذر ، به خطأ: FATAL:electron_main_delegate.cc(211)]

ولكن عندما أقوم بتثبيت snap بعد ， تشغيل كجذر أو المستخدم العادي على ما يرام。

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 sandbox (ربما جميع الحزم التي لا تشبه الحاوية) ، هناك حاجة فقط لتعيين بت إذن SUID إلى chrome-sandbox ثنائي. لكن لا تقم بتعيين بت إذن SUID لحزمة Snap لأن Snap Store يرفض مثل هذه الأنواع من الحزم. لذلك قمت بتعيين SUID bit لجميع حزم Linux ، وتتوقع حزم Snap / AppImage التي تحصل على وضع الحماية المعطل ، والشفرة ذات الصلة .

مرحبًاvladimiry
لم أتمكن من الوصول إلى الرابط الذي أرفقته هنا. هل يمكن أن تساعد في ذلك؟
بالإضافة إلى ذلك ، هل كنت قادرًا على معرفة كيفية القيام بـ - no-sandbox في النص البرمجي بعد حزمة منشئ الإلكترون؟

شكرا

@ tushar-compro ، ها هو https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. لقد قمت بشكل أساسي بتعيين 4755 بت في البرنامج النصي لما بعد الحزم لبعض أنواع الحزم وما زلت أعيد حزم حزم appimage + snap. في الواقع ، قام منشئ الإلكترون بالفعل بتضمين --no-sandbox arg في Snap ولكن ليس بعد في التطبيق 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 بت للأهداف بخلاف التصور والتقاط الصور.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

لكن المشكلة تحدث أثناء استخدام .appimage installer على توزيعة دبيان.

نسيت شيئا ما هنا؟

لكن المشكلة تحدث أثناء استخدام .appimage installer على توزيعة دبيان.

كما قلت لا تزال الحياة تتطلب معاملة خاصة. أعدت حزمه وضمنت --no-sandbox في البرنامج النصي ./AppRun . حدد موقع الكلمة الرئيسية DISABLE_SANDBOX_ARGS_LINE هنا https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

لكن المشكلة تحدث أثناء استخدام .appimage installer على توزيعة دبيان.

كما قلت لا تزال الحياة تتطلب معاملة خاصة. أعدت حزمه وضمنت --no-sandbox في البرنامج النصي ./AppRun . حدد موقع الكلمة الرئيسية DISABLE_SANDBOX_ARGS_LINE هنا https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

يعتني منشئ الإلكترون الأحدث بحجة no sanbox تلقائيًا في كل من snap و appimage.

تضمين التغريدة
لذا ، أنا محق في فهم أن إعداد 4755 بت الذي قمت به مخصص للمثبتات بخلاف appimage and snap. وللحصول على appimage ، قمت بتعيين no-sandbox. هل يمكنك تأكيد ذلك.

@ p3x- الروبوت
نعم. أنت على حق جزئيًا.

1. أحدث منشئ الإلكترون لا يحدد وضع الحماية للقطات ولكن ليس للتخصيص. ومع ذلك ، فقد حددوا 4755 بت للتخصيص.
2. في مشروعي ، أستخدم الإصدار الإلكتروني 20.xx ، وسيكون تحديثه إلى 22.xx جهدًا في حد ذاته. مجرد محاولة لتجنب ذلك إذا كان ذلك ممكنا. التحديث إلى الإصدار 22 سيكون الملاذ الأخير.

يعتني منشئ الإلكترون الأحدث بحجة no sanbox تلقائيًا في كل من snap و appimage.

تعذر حتى الآن تحديد موقع المقتطف الخاص بالتطبيق المشابه لهذا المقطع المطبق على اللقطات (https://github.com/electron-userland/electron-builder/pull/4496 لا يزال مفتوحًا). على أي حال ، في حالتي ، لا يزال إعادة التعبئة مطلوبًا منذ أن وضعت هناك قوائم إضافية ، بخلاف المتعلقة بـ sanbox.

لذا ، أنا محق في فهم أن إعداد 4755 بت الذي قمت به مخصص للمثبتات بخلاف appimage and snap. وللحصول على appimage ، قمت بتعيين no-sandbox. هل يمكنك تأكيد ذلك.

صيح. لكن منشئ الإلكترون الحديث يحدد 4755 داخليًا. أتحقق من أنه لم يتم ضبطه على Snap / appimage لأن ذلك سيكون خطأ. على سبيل المثال ، لن يبدأ Snap بـ 4755 بت مضبوطًا على ثنائي الإلكترون إذا كنت أتذكر الأشياء بشكل صحيح.

تضمين التغريدة
أنا فقط بحاجة إلى تعيين no-sandbox لأن تطبيقاتي لا تعمل في دبيان.

أعتقد أنني لن أحتاج إلى إعادة التعبئة في هذه الحالة. لكن لم أتمكن من العثور على التوثيق الصحيح لمنشئ الإلكترون للقيام بذلك. أو هل تعتقد أنني سأحتاج أيضًا إلى إعادة التعبئة؟

هل يمكنك أن تدلني على الوثائق الصحيحة التي يمكن أن تساعدني في كيفية القيام بذلك.

بالإضافة إلى ذلك ، أفهم أن لدي كلا الخيارين إما تعيين 4755 بت أو عدم وضع الحماية.
أي واحدة أفضل برأيك؟

بالإضافة إلى ذلك ، أفهم أن لدي كلا الخيارين إما تعيين 4755 بت أو عدم وضع الحماية.

إذا كنت أتذكر الأشياء بشكل صحيح ، فإن الإعدادات 4755 للتخصيص لن تحل المشكلة. تحتاج إلى (واحد من):

• ابدأ ملف appimage الخاص بك باستخدام سطر الأوامر --no-sandbox
• و --no-sandbox جزءا لا يتجزأ في ./AppRun النصي الموجود في ملف appimage (بحيث تحزيم الحاجة).

هل يمكنك أن تدلني على الوثائق الصحيحة التي يمكن أن تساعدني في كيفية القيام بذلك.

أشك في أنك ستجد معلومات مفصلة حول المشكلة في أي وثائق. لست على علم بأي مستندات ذات صلة.

بالإضافة إلى ذلك ، أفهم أن لدي كلا الخيارين إما تعيين 4755 بت أو عدم وضع الحماية.

إذا كنت أتذكر الأشياء بشكل صحيح ، فإن الإعدادات 4755 للتخصيص لن تحل المشكلة. تحتاج إلى (واحد من):

• ابدأ باستخدام سطر الأوامر --no-sandbox arg
• يكون --no-sandbox جزءا لا يتجزأ في ./AppRun النصي الموجود في ملف appiamge (بحيث تحزيم الحاجة).

هل يمكنك أن تدلني على الوثائق الصحيحة التي يمكن أن تساعدني في كيفية القيام بذلك.

أشك في أنك ستجد معلومات مفصلة حول المشكلة في أي وثائق. لست على علم بأي مستندات ذات صلة.

قام منشئ الإلكترون مؤخرًا بتضمين --no-sandbox في ./AppRun ، كنت أعيد حزمه ، لكن الآن أصبح عديم الفائدة ، أنا فقط استخدم منشئ الإلكترون الأصلي.

تضمين التغريدة
نعم. تعيين 4755 وحده لن يعمل. مع 4755 نحتاج إلى تغيير مالك chrome-sandbox إلى الجذر.
على أي حال ، شكرا جزيلا لمساعدتك. سأحاول إحالة الكود الخاص بك وتعيين no-sandbox بعد ذلك.

@ p3x- الروبوت
هل يمكنك مشاركة بعض الروابط (repo منشئ الإلكترون) حيث يمكننا رؤية الكود يقوم بذلك.

https://github.com/patrikx3/onenote

تضمين التغريدة
نعم. تعيين 4755 وحده لن يعمل. مع 4755 نحتاج إلى تغيير مالك chrome-sandbox إلى الجذر.
على أي حال ، شكرا جزيلا لمساعدتك. سأحاول إحالة الكود الخاص بك وتعيين no-sandbox بعد ذلك.

@ p3x- الروبوت
هل يمكنك مشاركة بعض الروابط (repo منشئ الإلكترون) حيث يمكننا رؤية الكود يقوم بذلك.

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 -like. ربما تكون قد قمت بتمكين علامة 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 -like. ربما تكون قد قمت بتمكين علامة 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/snap.ts#L197 -ل 202.

هناك 10 كيلو مبكرة

نحن نتحدث عن appimage ، وليس الشيء المفاجئ. Snap بالطبع يحتوي على الوسيطة المضمنة كما أشرت أعلاه ، هنا https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -ل 202.

أنت محق. كنت أفكر لسبب ما في أن ذلك تم إجراؤه في appimage ، حتى أنني أزلت رمز إعادة الحزمة وأضفت no-sandbox ، لكنني حاولت مرة أخرى وأرى أنه مفقود ، لذلك أضفت رجعي عن بنائي ، لا يعمل. آسف ، في corifeus-builder الخاص بي ، يمكنك رؤية ما أفعله: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

مرحبًا nornagon مع الأخذ في الاعتبار مدى شيوع هذه المشكلة ، هل يمكن تحديث البرنامج التعليمي الرسمي للبدء السريع للإلكترون ليشمل الحل البديل حتى يتمتع المبتدئون بتجربة إيجابية؟

تحرير: بفضل تشجيع المجتمع لقد فتحت FR # 26478

gabefair هذا يبدو وكأنه اقتراح معقول. هل أنت مهتم بفتح العلاقات العامة؟