English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Tools

موافقات التنفيذ — متقدمة

موضوعات متقدمة في موافقات exec: المسار السريع safeBins، وربط المفسّر/بيئة التشغيل، وتمرير الموافقات إلى قنوات الدردشة (بما في ذلك التسليم الأصلي). للاطلاع على السياسة الأساسية وتدفق الموافقات، راجع موافقات Exec.

الثنائيات الآمنة (stdin فقط)

يعرّف tools.exec.safeBins قائمة صغيرة من الثنائيات التي تعمل عبر stdin فقط (مثل cut) ويمكن تشغيلها في وضع قائمة السماح من دون إدخالات صريحة في قائمة السماح. ترفض الثنائيات الآمنة وسائط الملفات الموضعية والرموز الشبيهة بالمسارات، لذلك لا يمكنها العمل إلا على الدفق الوارد. تعامل مع هذا باعتباره مسارًا سريعًا ضيقًا لفلاتر التدفق، وليس قائمة ثقة عامة.

الثنائيات الآمنة الافتراضية:

cut, uniq, head, tail, tr, wc

لا يندرج grep وsort ضمن القائمة الافتراضية. إذا اخترت تفعيلهما، فاحتفظ بإدخالات قائمة سماح صريحة لسير عملهما غير المعتمد على stdin. بالنسبة إلى grep في وضع الثنائيات الآمنة، قدّم النمط باستخدام -e/--regexp؛ يُرفض شكل النمط الموضعي حتى لا يمكن تمرير معاملات الملفات خفية كوسائط موضعية ملتبسة.

التحقق من argv والرايات المرفوضة

يكون التحقق حتميًا من شكل argv فقط (من دون فحوصات وجود على نظام ملفات المضيف)، ما يمنع سلوك كاشف وجود الملفات الناتج عن اختلافات السماح/المنع. تُرفض الخيارات الموجّهة للملفات في الثنائيات الآمنة الافتراضية؛ وتُتحقق الخيارات الطويلة بطريقة تغلق عند الفشل (تُرفض الرايات غير المعروفة والاختصارات الملتبسة).

الرايات المرفوضة حسب ملف تعريف الثنائي الآمن:

  • grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
  • jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
  • sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
  • wc: --files0-from

تفرض الثنائيات الآمنة أيضًا معاملة رموز argv كنص حرفي وقت التنفيذ (من دون توسيع glob ومن دون توسيع $VARS) للمقاطع المعتمدة على stdin فقط، لذلك لا يمكن استخدام أنماط مثل * أو $HOME/... لتمرير قراءات ملفات خفية.

أدلة الثنائيات الموثوقة

يجب أن تُحلّ الثنائيات الآمنة من أدلة ثنائيات موثوقة (افتراضيات النظام بالإضافة إلى tools.exec.safeBinTrustedDirs الاختيارية). لا تُعد إدخالات PATH موثوقة تلقائيًا أبدًا. الأدلة الموثوقة الافتراضية قليلة عمدًا: /bin, /usr/bin. إذا كان تنفيذ الثنائي الآمن لديك موجودًا في مسارات مدير الحزم/المستخدم (مثل /opt/homebrew/bin و/usr/local/bin و/opt/local/bin و/snap/bin)، فأضفها صراحة إلى tools.exec.safeBinTrustedDirs.

تسلسل الصَدَفة، والمغلّفات، والمبدّلات

يُسمح بتسلسل الصَدَفة (&& و|| و;) عندما يفي كل مقطع من المستوى الأعلى بقائمة السماح (بما في ذلك الثنائيات الآمنة أو السماح التلقائي للمهارة). تبقى إعادة التوجيه غير مدعومة في وضع قائمة السماح. يُرفض استبدال الأوامر ($() / علامات الاقتباس العكسية) أثناء تحليل قائمة السماح، بما في ذلك داخل علامات الاقتباس المزدوجة؛ استخدم علامات الاقتباس المفردة إذا احتجت إلى نص $() حرفي.

في موافقات التطبيق المرافق على macOS، يُعامل نص الصَدَفة الخام الذي يحتوي على صياغة تحكم أو توسيع للصَدَفة (&& و|| و; و| و` و$ و< و> و( و)) كتفويت لقائمة السماح ما لم يكن ثنائي الصَدَفة نفسه موجودًا في قائمة السماح.

بالنسبة إلى مغلّفات الصَدَفة (bash|sh|zsh ... -c/-lc)، تُقلَّص تجاوزات البيئة المحددة بنطاق الطلب إلى قائمة سماح صريحة صغيرة (TERM وLANG وLC_* وCOLORTERM وNO_COLOR وFORCE_COLOR).

بالنسبة إلى قرارات allow-always في وضع قائمة السماح، تحفظ مغلّفات الإرسال المعروفة (env وnice وnohup وstdbuf وtimeout) مسار الملف التنفيذي الداخلي بدلًا من مسار المغلّف. تُفك مغلّفات مبدّلات الصَدَفة (busybox وtoybox) لتطبيقات الصَدَفة الصغيرة (sh وash وما شابه) بالطريقة نفسها. إذا تعذر فك مغلّف أو مبدّل بأمان، فلا يُحفظ أي إدخال في قائمة السماح تلقائيًا.

إذا أضفت مفسّرات مثل python3 أو node إلى قائمة السماح، ففضّل tools.exec.strictInlineEval=true حتى يظل التقييم المضمّن يتطلب موافقة صريحة. في الوضع الصارم، لا يزال بإمكان allow-always حفظ استدعاءات المفسّر/السكربت غير الضارة، لكن حوامل التقييم المضمّن لا تُحفظ تلقائيًا.

الثنائيات الآمنة مقابل قائمة السماح

الموضوع tools.exec.safeBins قائمة السماح (exec-approvals.json)
الهدف السماح التلقائي لفلاتر stdin الضيقة الثقة الصريحة بملفات تنفيذية محددة
نوع المطابقة اسم الملف التنفيذي + سياسة argv للثنائي الآمن نمط glob لمسار الملف التنفيذي المحلول، أو نمط glob لاسم الأمر المجرد للأوامر المستدعاة عبر PATH
نطاق الوسائط مقيّد بملف تعريف الثنائي الآمن وقواعد الرمز الحرفي مطابقة المسار افتراضيًا؛ يمكن لـargPattern الاختياري تقييد argv المحلّل
أمثلة نموذجية head, tail, tr, wc jq, python3, node, ffmpeg, واجهات CLI مخصصة
أفضل استخدام تحويلات نصية منخفضة المخاطر في خطوط المعالجة أي أداة ذات سلوك أوسع أو آثار جانبية

موقع الإعداد:

  • يأتي safeBins من الإعداد (tools.exec.safeBins أو agents.list[].tools.exec.safeBins لكل وكيل).
  • يأتي safeBinTrustedDirs من الإعداد (tools.exec.safeBinTrustedDirs أو agents.list[].tools.exec.safeBinTrustedDirs لكل وكيل).
  • يأتي safeBinProfiles من الإعداد (tools.exec.safeBinProfiles أو agents.list[].tools.exec.safeBinProfiles لكل وكيل). تتجاوز مفاتيح ملف التعريف لكل وكيل المفاتيح العامة.
  • توجد إدخالات قائمة السماح في ~/.openclaw/exec-approvals.json المحلي للمضيف تحت agents.<id>.allowlist (أو عبر Control UI / openclaw approvals allowlist ...).
  • يحذّر openclaw security audit باستخدام tools.exec.safe_bins_interpreter_unprofiled عندما تظهر ثنائيات المفسّر/بيئة التشغيل في safeBins من دون ملفات تعريف صريحة.
  • يستطيع openclaw doctor --fix إنشاء إدخالات safeBinProfiles.<bin> المخصصة المفقودة كـ{} (راجعها وشددها بعد ذلك). لا تُنشأ ثنائيات المفسّر/بيئة التشغيل تلقائيًا.

مثال ملف تعريف مخصص: OC_I18N_900000 إذا أدخلت jq صراحة في safeBins، فسيظل OpenClaw يرفض env المدمج في وضع الثنائيات الآمنة حتى لا يتمكن jq -n env من تفريغ بيئة عملية المضيف من دون مسار قائمة سماح صريح أو مطالبة موافقة.

أوامر المفسّر/بيئة التشغيل

تشغيلات المفسّر/بيئة التشغيل المدعومة بالموافقة محافظة عمدًا:

  • يكون سياق argv/cwd/env الدقيق مربوطًا دائمًا.
  • تُربط أشكال سكربت الصَدَفة المباشر وملف بيئة التشغيل المباشر، بأفضل جهد، بلقطة واحدة لملف محلي ملموس.
  • تُفك أشكال مغلّفات مديري الحزم الشائعة التي لا تزال تُحل إلى ملف محلي مباشر واحد (مثل pnpm exec وpnpm node وnpm exec وnpx) قبل الربط.
  • إذا تعذر على OpenClaw تحديد ملف محلي ملموس واحد بالضبط لأمر مفسّر/بيئة تشغيل (مثل سكربتات الحزم، أو أشكال التقييم، أو سلاسل التحميل الخاصة ببيئة التشغيل، أو الأشكال متعددة الملفات الملتبسة)، يُرفض التنفيذ المدعوم بالموافقة بدلًا من ادعاء تغطية دلالية لا يملكها.
  • بالنسبة إلى هذه المسارات، فضّل العزل، أو حدًا منفصلًا للمضيف، أو قائمة سماح/سير عمل كاملًا موثوقًا صريحًا يقبل فيه المشغّل دلالات بيئة التشغيل الأوسع.

عندما تكون الموافقات مطلوبة، تعيد أداة exec فورًا معرّف موافقة. استخدم ذلك المعرّف لربط أحداث النظام اللاحقة (Exec finished / Exec denied). إذا لم يصل أي قرار قبل انتهاء المهلة، يُعامل الطلب كانتهاء مهلة موافقة ويُعرض كسبب رفض.

سلوك تسليم المتابعة

بعد انتهاء exec غير المتزامن الموافق عليه، يرسل OpenClaw دور agent للمتابعة إلى الجلسة نفسها.

  • إذا كان هدف تسليم خارجي صالح موجودًا (قناة قابلة للتسليم بالإضافة إلى هدف to)، يستخدم تسليم المتابعة تلك القناة.
  • في تدفقات webchat فقط أو الجلسات الداخلية التي لا تملك هدفًا خارجيًا، يبقى تسليم المتابعة للجلسة فقط (deliver: false).
  • إذا طلب المستدعي صراحة تسليمًا خارجيًا صارمًا من دون قناة خارجية قابلة للحل، يفشل الطلب مع INVALID_REQUEST.
  • إذا كان bestEffortDeliver مفعّلًا ولم يمكن حل أي قناة خارجية، يُخفّض التسليم إلى الجلسة فقط بدلًا من الفشل.

تمرير الموافقات إلى قنوات الدردشة

يمكنك تمرير مطالبات موافقة exec إلى أي قناة دردشة (بما في ذلك قنوات Plugin) والموافقة عليها باستخدام /approve. يستخدم هذا خط تسليم الصادر المعتاد.

الإعداد: OC_I18N_900001 الرد في الدردشة: OC_I18N_900002 يتعامل أمر /approve مع موافقات exec وموافقات Plugin معًا. إذا لم يطابق المعرّف موافقة exec معلقة، فإنه يتحقق تلقائيًا من موافقات Plugin بدلًا من ذلك.

تمرير موافقات Plugin

يستخدم تمرير موافقات Plugin خط التسليم نفسه المستخدم لموافقات exec، لكنه يملك إعدادًا مستقلًا خاصًا به تحت approvals.plugin. لا يؤثر تفعيل أحدهما أو تعطيله في الآخر. OC_I18N_900003 شكل الإعداد مطابق لـapprovals.exec: تعمل enabled وmode وagentFilter و sessionFilter وtargets بالطريقة نفسها.

تعرض القنوات التي تدعم الردود التفاعلية المشتركة أزرار الموافقة نفسها لموافقات exec وموافقات Plugin. القنوات التي لا تملك واجهة تفاعلية مشتركة تعود إلى نص عادي يتضمن تعليمات /approve. قد تقيّد طلبات موافقة Plugin القرارات المتاحة. تستخدم واجهات الموافقة مجموعة القرارات المعلنة في الطلب، ويرفض Gateway محاولات إرسال قرار لم يكن معروضًا.

الموافقات من الدردشة نفسها على أي قناة

عندما ينشأ طلب موافقة exec أو Plugin من واجهة دردشة قابلة للتسليم، يمكن للدردشة نفسها الآن الموافقة عليه باستخدام /approve افتراضيًا. ينطبق هذا على قنوات مثل Slack وMatrix وMicrosoft Teams بالإضافة إلى تدفقات Web UI وواجهة الطرفية الحالية.

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

يدعم Discord وTelegram أيضًا /approve من الدردشة نفسها، لكن هاتين القناتين لا تزالان تستخدمان قائمة الموافقين المحلولة لديهما للتفويض حتى عندما يكون تسليم الموافقات الأصلي معطلًا.

بالنسبة إلى Telegram وعملاء الموافقة الأصليين الآخرين الذين يستدعون Gateway مباشرة، فإن هذا الرجوع محدود عمدًا بإخفاقات "الموافقة غير موجودة". لا يُعاد محاولة رفض/خطأ حقيقي في موافقة exec بصمت كموافقة Plugin.

تسليم الموافقات الأصلي

يمكن لبعض القنوات أيضًا أن تعمل كعملاء موافقة أصليين. يضيف العملاء الأصليون رسائل DM للموافقين، وتوزيعًا إلى دردشة المصدر، وتجربة موافقة تفاعلية خاصة بالقناة فوق تدفق /approve المشترك في الدردشة نفسها.

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

إذا تم تكوين عميل موافقة أصلي لكن لا يوجد وقت تشغيل أصلي نشط للقناة الأصلية، يُبقي OpenClaw مطالبة /approve المحلية الحتمية مرئية. إذا كان وقت التشغيل الأصلي نشطًا وحاول التسليم لكن لم يتلقَّ أي هدف البطاقة، يرسل OpenClaw إشعار رجوع في الدردشة نفسها يتضمن أمر /approve <id> <decision> الدقيق بحيث يمكن حل الطلب مع ذلك.

النموذج العام:

  • ما زالت سياسة تنفيذ المضيف تقرر ما إذا كانت موافقة exec مطلوبة
  • يتحكم approvals.exec في تمرير مطالبات الموافقة إلى وجهات دردشة أخرى
  • يتحكم channels.<channel>.execApprovals فيما إذا كانت تلك القناة تعمل كعميل موافقة أصلي

يفعّل عملاء الموافقة الأصليون التسليم إلى رسائل DM أولًا تلقائيًا عندما تكون كل الشروط التالية صحيحة:

  • تدعم القناة تسليم الموافقة الأصلي
  • يمكن حلّ الموافقين من execApprovals.approvers الصريح أو من هوية المالك مثل commands.ownerAllowFrom
  • يكون channels.<channel>.execApprovals.enabled غير مضبوط أو "auto"

اضبط enabled: false لتعطيل عميل موافقة أصلي صراحةً. اضبط enabled: true لفرض تشغيله عندما يمكن حلّ الموافقين. يبقى التسليم العام إلى دردشة المصدر صريحًا عبر channels.<channel>.execApprovals.target.

الأسئلة الشائعة: لماذا يوجد إعدادا موافقة exec لموافقات الدردشة؟

  • Discord: channels.discord.execApprovals.*
  • Slack: channels.slack.execApprovals.*
  • Telegram: channels.telegram.execApprovals.*

يضيف عملاء الموافقة الأصليون هؤلاء توجيه رسائل DM وتوزيعًا اختياريًا إلى القناة فوق تدفق /approve المشترك في الدردشة نفسها وأزرار الموافقة المشتركة.

السلوك المشترك:

  • تستخدم Slack وMatrix وMicrosoft Teams والدردشات القابلة للتسليم المشابهة نموذج مصادقة القناة العادي لـ /approve في الدردشة نفسها
  • عندما يتفعّل عميل موافقة أصلي تلقائيًا، يكون هدف التسليم الأصلي الافتراضي هو رسائل DM للموافقين
  • بالنسبة إلى Discord وTelegram، لا يستطيع إلا الموافقون الذين تم حلّهم الموافقة أو الرفض
  • يمكن أن يكون موافقو Discord صريحين (execApprovals.approvers) أو مستنتجين من commands.ownerAllowFrom
  • يمكن أن يكون موافقو Telegram صريحين (execApprovals.approvers) أو مستنتجين من commands.ownerAllowFrom
  • يمكن أن يكون موافقو Slack صريحين (execApprovals.approvers) أو مستنتجين من commands.ownerAllowFrom
  • تحفظ أزرار Slack الأصلية نوع معرّف الموافقة، بحيث تستطيع معرّفات plugin: حل موافقات Plugin دون طبقة رجوع ثانية محلية في Slack
  • يتعامل توجيه DM/القناة الأصلي في Matrix واختصارات التفاعل مع موافقات exec وPlugin؛ ما زال تفويض Plugin يأتي من channels.matrix.dm.allowFrom
  • تتضمن مطالبات Matrix الأصلية محتوى حدث مخصص com.openclaw.approval في حدث المطالبة الأول بحيث يمكن لعملاء Matrix المدركين لـ OpenClaw قراءة حالة الموافقة المهيكلة بينما يحتفظ العملاء القياسيون برجوع /approve كنص عادي
  • لا يلزم أن يكون مقدم الطلب موافقًا
  • يمكن للدردشة الأصلية أن توافق مباشرة باستخدام /approve عندما تدعم تلك الدردشة الأوامر والردود بالفعل
  • توجّه أزرار موافقة Discord الأصلية حسب نوع معرّف الموافقة: تذهب معرّفات plugin: مباشرةً إلى موافقات Plugin، ويذهب كل شيء آخر إلى موافقات exec
  • تتبع أزرار موافقة Telegram الأصلية نفس الرجوع المحدود من exec إلى Plugin مثل /approve
  • عندما يفعّل target الأصلي التسليم إلى دردشة المصدر، تتضمن مطالبات الموافقة نص الأمر
  • تنتهي صلاحية موافقات exec المعلقة بعد 30 دقيقة افتراضيًا
  • إذا لم تستطع أي واجهة مشغّل أو عميل موافقة مكوّن قبول الطلب، تعود المطالبة إلى askFallback

تستخدم أوامر المجموعات الحساسة الخاصة بالمالك فقط مثل /diagnostics و/export-trajectory توجيهًا خاصًا بالمالك لمطالبات الموافقة والنتائج النهائية. يحاول OpenClaw أولًا استخدام مسار خاص على نفس السطح الذي شغّل فيه المالك الأمر. إذا لم يكن لذلك السطح مسار مالك خاص، فإنه يعود إلى أول مسار مالك متاح من commands.ownerAllowFrom، بحيث يستطيع أمر مجموعة Discord مع ذلك إرسال الموافقة والنتيجة إلى DM مالك Telegram عندما تكون Telegram هي الواجهة الخاصة الأساسية المكوّنة. لا تحصل دردشة المجموعة إلا على إقرار قصير.

تستخدم Telegram افتراضيًا رسائل DM للموافقين (target: "dm"). يمكنك التبديل إلى channel أو both عندما تريد أن تظهر مطالبات الموافقة في دردشة/موضوع Telegram الأصلي أيضًا. بالنسبة إلى مواضيع منتدى Telegram، يحافظ OpenClaw على الموضوع لمطالبة الموافقة والمتابعة اللاحقة للموافقة.

راجع:

تدفق IPC في macOS

OC_I18N_900004 ملاحظات الأمان:

  • وضع مقبس Unix هو 0600، والرمز مخزّن في exec-approvals.json.
  • فحص النظير ذي UID نفسه.
  • تحدي/استجابة (nonce + HMAC token + request hash) + TTL قصير.

ذات صلة