क्या 'chown यूजर: यूजर लॉस्ट + फाउंड' हानिकारक है?

Question

हाल ही में मैंने एक एन्क्रिप्टेड फाइलसिस्टम ( crypto_LUKS) बनाया जो केवल एक विशेष उपयोगकर्ता के लिए $ HOME के ​​रूप में कार्य करता है (यानी मैं इसे माउंट करता हूं /home/pduck)। मैंने एक उचित प्रविष्टि भी जोड़ी है /etc/security/pam_mount.conf.xmlताकि उपयोगकर्ता के लॉग इन करते समय विभाजन स्वचालित रूप से डिक्रिप्ट और माउंट हो जाए (और जब वह लॉग ऑफ हो तो अनमाउंट हो जाए)। बहुत अच्छा काम करता है।

चूँकि $ HOME अपने आप में एक फाइल सिस्टम है, इसलिए उपयोगकर्ता के पास lost+foundरूट: रूट में स्वामित्व वाली निर्देशिका है। मुझे पता है कि निर्देशिका को हटाना एक बुरा विचार है, लेकिन कई आदेशों (जैसे find) की पहुंच न होने की शिकायत करते हैं। जो मुझे गुस्सा दिलाता है।

जिज्ञासा से बाहर मैंने निर्देशिका को हटा दिया और इसे mklost+found(बिना sudo) के साथ फिर से बनाया । अब निर्देशिका pduck: pduck के स्वामित्व में है। क्या यह ठीक है या यह महत्वपूर्ण है कि निर्देशिका रूट: रूट के स्वामित्व में है?

Comments

सभी फ़ाइल सिस्टम में एक खोई हुई + मिली निर्देशिका नहीं है। Ext4 करता है, XFS उदाहरण के लिए, नहीं करता है।

— jornane

उत्तर नहीं है, लेकिन आप केवल खोजने के लिए एक स्क्रिप्ट या उपनाम बना सकते हैं (अधिमानतः एक अलग नाम के साथ) 2>/dev/nullजो उन त्रुटि संदेशों को शांत करता है। यदि आप इसे शुरुआत में रखते हैं, तो यह प्रत्येक आह्वान में खोजने के लिए जो भी तर्क आप पास करना चाहते हैं, उसमें हस्तक्षेप नहीं करेंगे।

— जो

Answer 1

अच्छी सलाह एक तर्क के साथ आती है ताकि आप यह बता सकें कि यह कब बुरी सलाह बन जाती है।

lost+foundजड़ के स्वामित्व का उद्देश्य इतना है कि कोई फर्क नहीं पड़ता कि किसकी फाइल थी जो खो गई थी, यह अचानक हर किसी के संपर्क में नहीं है। हालाँकि, इस मामले में, पूरे फाइलसिस्टम में एक भी फाइल नहीं होनी चाहिए * pduck के स्वामित्व में नहीं; इसलिए lost+foundpduck के स्वामित्व में नहीं होने का कोई नकारात्मक पहलू नहीं है।

* pduck की तरह विदेशी परिस्थितियों को छोड़कर suरूट को लागू करना और X अनुप्रयोग चलाना। लेकिन अगर pduck का उपयोग कर सकते हैं sudoया suहम कुछ भी नहीं के बारे में बात कर रहे हैं क्योंकि pduck एकमुश्त सिस्टम सुरक्षा को तोड़ सकता है।

Answer 2

lost+found एक सिस्टम डायरेक्टरी है, और मैं सिस्टम डाइरेक्टरीज़ और फाइल्स के स्वामित्व और अनुमतियों के साथ छेड़छाड़ करने से बचता हूँ।

अन्य निर्देशिकाएं (और फाइलें) हैं, जो findशिकायत करती हैं, जब तक कि मैं कमांड लाइन की अनुमतियों को नहीं बढ़ाता हूं, इसलिए मैं सुझाव देता हूं कि आप उपयोग करें

sudo find ...

और lost+foundइसे छोड़ दें {यह है / होना चाहिए}।

Comments

हां, इसलिए मैंने सोचा, लेकिन ओटीओएच mklost+foundइसे बनाने के लिए कमांड है और यह इसे मेरे स्वामित्व के साथ बनाता है । हो सकता है कि यह सिर्फ एक बुरी तरह से लिखी गई कमांड है, जिसके लिए कोई जांच नहीं करता; $UID!=0;-) इसके अलावा, मुझे sudoअपने बहुत ही $ HOME में उपयोग करने के लिए मजबूर (कम या ज्यादा) होने का विचार पसंद नहीं है ।

— पर्लडक

lost+foundबहुत पुराना है, मुझे लगता है कि यह शुरुआती UNIX दिनों से है, और मुझे वास्तव में नहीं पता है कि इसका उपयोग कब किया जाता है। लेकिन मुझे लगता है कि यह सिस्टम निर्देशिका और फ़ाइलों के स्वामित्व और अनुमतियों के साथ छेड़छाड़ से बचने के लिए एक अच्छी सामान्य नीति है (जब तक कि आपको वास्तव में पता नहीं है कि दृश्य के पीछे क्या हो सकता है)।

— sudodus

fsckजब यह "खोई" फ़ाइलों का सामना करता है तो वहां फाइलें नहीं रखता है? विचार यह है कि fsckपहले से ही फाइलों को डालने की जगह है (पहले बनाने की बजाय)। ध्यान दें कि lost+foundएक साधारण खाली निर्देशिका (4096 बाइट्स) की तुलना में अधिक स्थान (16384 बाइट्स) व्याप्त है।

— पर्लडक

हां, कम से कम यह मूल उद्देश्य ( chkdskMSDOS में खोई हुई फ़ाइलों के साथ जैसा था ) के समान था, लेकिन मुझे शायद ही कभी ऐसा हुआ हो जब कभी भी किसी भी डेटा को लिनक्स में देखा गया हो। हो सकता है कि जर्नलिंग उन फ़ाइलों को पुनर्स्थापित कर सके जहां वे पहले थे, इसलिए उन्हें जाने की आवश्यकता नहीं है lost+found। - वैसे, मेरे पास एक lost+foundनिर्देशिका है /home, लेकिन मेरे घर की निर्देशिका में नहीं है /home/sudodus, इसलिए यह मुझे वहां परेशान नहीं करता है।

— सूदोदास

मैं सहमत हूँ। और /homeमेरे पास एक और है l+f(मुझे परेशान नहीं करता है) क्योंकि /homeऔर /home/pduckमेरी मशीन पर अलग विभाजन हैं। बाद को एन्क्रिप्ट किया गया है, पूर्व नहीं है। हालाँकि, जब यह मुझे बहुत अधिक परेशान करता है, तो मैं अपना $ HOME कहीं और माउंट कर सकता हूँ और इसे अपने वास्तविक $ HOME (जैसे मैं यहाँ उल्लिखित किया जाता है ) पर माउंट कर सकता हूँ , पूरी तरह l+fसे मेरे $ HOME से छुटकारा पाने के लिए । /// मैं कुछ मिनटों / घंटों में अपनी टिप्पणियों को हटा दूँगा कि "विस्तारित चर्चा ... चैट पर जाएँ" अलर्ट से बचने के लिए ।

— पेरलुक

Answer 3

खोई हुई + मिली हुई निर्देशिका के बारे में वास्तव में कुछ भी जादुई नहीं है। यह किसी अन्य की तरह ही एक सादा निर्देशिका है और सिस्टम क्रैश या सिस्टम सिस्टम भ्रष्टाचार के बाद fsck के दौरान मिली खोई हुई फ़ाइलों / निर्देशिकाओं को रखने के लिए उपयोग किया जाता है।

यह फाइल सिस्टम बनाने और सामान्य रूप से खाली होने पर mkfs के दौरान बनाया जाता है। डिफ़ॉल्ट अनुमतियों का एकमात्र कारण संवेदनशील फ़ाइलों को नियमित उपयोगकर्ताओं को दिखाई देने से बचने के लिए है यदि वे फ़ॉस्क के दौरान पाए जाते हैं और पुनर्प्राप्त किए जाते हैं। आधुनिक युग में फाइलों को खो जाना और उस फ़ोल्डर में डालना दुर्लभ है।

यदि इसे हटा दिया गया है, तो मेरा मानना ​​है कि fsck इसे फिर से आवश्यकतानुसार बनाएगा यदि कोई ऐसी फ़ाइलें होती हैं जिन्हें वहां डालने की आवश्यकता होती है। चूँकि यह एक उपयोगकर्ता और उसके डेटा के लिए एक फाइल सिस्टम है, जिसकी कोई ज़रूरत नहीं है, डेटा को चुभने वाली आँखों से छिपाए रखने के लिए, मुझे कोई कारण नहीं दिखता कि अनुमतियों को शिकायत में बदलने या इसे बदलने से रोकने के लिए 755 में नहीं कहा जा सकता। स्वामित्व। यह संभव है कि पुनर्प्राप्ति प्रक्रिया के दौरान fsck इसे रीसेट कर सकता है, लेकिन आधुनिक फ़ाइल सिस्टम पर यह एक दुर्लभ घटना है जब तक कि गंभीर हार्डवेयर विफलता नहीं होती है।

इसे हटाने के लिए, मुझे विश्वास है कि आसपास के सभी व्यामोह इस तथ्य पर आधारित हैं कि डेटा को पुनर्प्राप्त करने के लिए जितना संभव हो कम से कम fsck करना सबसे अच्छा है, लेकिन मुझे नहीं लगता कि यह वास्तव में बहुत ज्यादा मायने रखता है।