Rm को किसी भिन्न उपयोगकर्ता के स्वामित्व के तहत फ़ाइल को हटाने की अनुमति क्यों है?


52

पोस्ट से rm केवल-पढ़ने के लिए फ़ाइलें क्यों निकाल सकता है? मैं समझता हूं कि rmफ़ाइल को हटाने के लिए बस डायरेक्टरी पर लिखने की अनुमति चाहिए। लेकिन मुझे उस व्यवहार को पचाने में मुश्किल होती है जहां हम एक फ़ाइल को आसानी से हटा सकते हैं जो मालिक और समूह अलग है।

मैंने निम्नलिखित की कोशिश की

mtk: मेरा उपयोगकर्ता नाम
abc: एक नया उपयोगकर्ता बनाया

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

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

जवाबों:


100

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

और, किसी निर्देशिका से नाम प्रविष्टि को हटाना मूल रूप से उस निर्देशिका पर एक ऑपरेशन है , इसलिए वह निर्देशिका वह चीज़ है जिसे आपको लिखने की अनुमति होनी चाहिए।


निम्नलिखित परिदृश्य इसे और अधिक आरामदायक महसूस कर सकता है? मान लीजिए कि निर्देशिकाएं हैं:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

और एक फाइल है जो मेरे स्वामित्व में है और जिसमें दो हार्ड लिंक हैं:

/home/me/myfile
/home/you/myfile

कभी नहीं सोचा कि /home/you/myfileपहली बार में उस कड़ी को कैसे मिला। शायद rootवहाँ रख दिया जाए।

इस उदाहरण का विचार यह है कि आपको हार्ड लिंक को हटाने की अनुमति दी जानी चाहिए /home/you/myfile। सब के बाद, यह आपकी निर्देशिका को अव्यवस्थित कर रहा है । आपको यह नियंत्रित करने में सक्षम होना चाहिए कि क्या करता है और अंदर मौजूद नहीं है /home/you। और जब आप हटाते हैं /home/you/myfile, तो ध्यान दें कि आपने वास्तव में फ़ाइल को हटाया नहीं है। आपने केवल एक लिंक निकाला है।


ध्यान दें कि यदि चिपचिपा सा निर्देशिका एक फ़ाइल (के रूप में दिखाई युक्त पर सेट किया गया है tमें ls), तो आप करते हैं फ़ाइल के मालिक होने के लिए इसे हटाने के लिए अनुमति दी जा (जब तक आप निर्देशिका के मालिक हैं) की जरूरत है। चिपचिपा सा आमतौर पर सेट किया जाता है /tmp


6
निर्देशिका पर चिपचिपा बिट के साथ, आपको इसे हटाने की अनुमति दी जाने वाली फ़ाइल को संशोधित करने में सक्षम होने की आवश्यकता है। यही है, यदि फ़ाइल आपके समान समूह में किसी और की है, और समूह फ़ाइल को लिख सकता है, तो आप फ़ाइल को निकाल सकते हैं। कोरोलरी: कोई भी सार्वजनिक लिखित अनुमति के साथ एक फ़ाइल निकाल सकता है। (निर्देशिका को संशोधित करने में सक्षम होने के लिए सभी विषय।)
जोनाथन लेफ़लर

1
मैं आपको गलत समझ सकता हूं लेकिन क्या आप यह नहीं कह रहे हैं कि मैं -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/fooअपने नियमित उपयोगकर्ता के रूप में हटा सकता हूं ( /tmpचिपचिपा है) क्योंकि मुझे इसे लिखने की अनुमति है? फिर भी मैं नहीं कर सकता।
सेलाडा

4
मेरा मानना ​​है कि me/ youपरिदृश्य स्पष्ट ध्यान में आता है यदि आप यह अनुमान लगाते हैं कि उपयोगकर्ता (जो फ़ाइल के मालिक नहीं है) ने लिंक बनाया है। सर्वनाम का उपयोग करना मुश्किल है; मान लीजिए कि अल क्रिएट होता है /home/al/file1, और बॉब, जिसने /home/alफ़ाइल को हार्ड-लिंक से एक्सेस (और शायद पढ़ा) तक पहुँचाया है /home/bob/als_file। बॉब एक लिंक को हटाने से रोका जाना चाहिए कि वह बनाया?   और /home/bob/als_fileजब उसे लिखने की अनुमति न हो, तो क्या अल को हटाने (अनलिंक करने) की अनुमति दी जानी चाहिए /home/bob? इस सड़क से अराजकता होती है।
स्कॉट

2
@JonathanLeffler: स्कॉट उदाहरण दिखाता है के रूप में, नहीं, अनलिंक और छोटा है ही शुद्ध परिणाम जब खेल में हार्ड लिंक देखते हैं की है।
केविन

6
@ केविन मुझे लगता है कि अगर किसी के पास फ़ाइल की अनुमति है, तो वह सामग्री को नष्ट कर सकता है, तो उसे भी इसे अनलिंक करने की अनुमति दी जा सकती है (यह मानते हुए कि उसने निर्देशिका की अनुमति भी लिखी है)। अनुलग्‍नक लागू नहीं होता है - एक निर्देशिका से फ़ाइल को निकालने में सक्षम होने का मतलब यह नहीं है कि वह सामग्री को नष्ट करने में सक्षम होना चाहिए, क्योंकि वे किसी अन्य निर्देशिका से सुलभ हो सकते हैं। स्टिकी बिट कैसे काम करता है, इसके पीछे यही तर्क है।
बमर

9

किसी फ़ाइल को निकालने के लिए, आपको बस उस निर्देशिका को लिखने में सक्षम होना चाहिए जो फ़ाइल में है।

यदि आपको यह पसंद नहीं है, तो आप "चिपचिपा" बिट के माध्यम से सेट कर सकते chmod +t dirहैं यदि आप आधे हाल के ओएस पर हैं (यह सुविधा सनोस में 1986 के आसपास पेश की गई थी)।

यदि आपको अधिक बारीक अनाज पसंद है, तो आपको ZFS जैसे आधुनिक ACL कार्यान्वयन के साथ फाइलसिस्टम की आवश्यकता है। NTFS पर आधारित मानक NFSv4 ACLs में प्रति उपयोगकर्ता विशिष्ट फ़ाइल हटाने की अनुमति और निर्देशिका के लिए "delete_child" अनुमति शामिल है।


9
ध्यान दें कि tबिट को जोड़ने के लिए , आपको निर्देशिका का मालिक होना चाहिए। और अगर आप डायरेक्टरी के मालिक हैं, तो आप हमेशा इस बात की परवाह किए बिना फाइल निकाल सकते हैं कि tबिट सेट है या नहीं। यदि आप किसी फ़ाइल को किसी और की निर्देशिका से लिंक करते हैं, तो आपको इसे हटाने में सक्षम होने के लिए किसी और के लिए तैयार रहना चाहिए। एक विकल्प यह होगा कि पहले आप अपनी उप-डायर बनाएं और इसके बजाय अपनी फ़ाइल को इसमें जोड़ें, क्योंकि मालिक खाली होने पर उस सबडिर को नहीं निकाल सकेगा।
स्टीफन चेजलस

6
आप स्थिति को भ्रामक तरीके से बताते हैं। तकनीकी रूप से, एक फ़ाइल एक निर्देशिका में नहीं है; बल्कि, फ़ाइल के लिए एक नाम निर्देशिका में है, और rmनिर्देशिका पर एक ऑपरेशन है, फ़ाइल पर नहीं। अंतिम संदर्भ को हटाए जाने पर कोई फ़ाइल निकाल दी जाती है, लेकिन तकनीकी रूप से, यह एक साइड इफेक्ट है।
रीयरियरपोस्ट

0

तर्क एक घर के समान है: मालिक या किरायेदार यह तय करता है कि कौन से मेहमानों को बाहर निकालना है, कोई फर्क नहीं पड़ता कि कौन मेहमानों का मालिक है। इसके अलावा, बेदखल किए गए अतिथि का दूसरे घर में स्वागत है (किसी और की निर्देशिका में एक और हार्डलिंक है) बाहर मौत को रोक नहीं पाएगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.