बनाई गई फ़ाइलों और फ़ोल्डरों पर मालिक को मजबूर करना

Question

मेरे पास एक निर्देशिका है जिसमें कई उपयोगकर्ताओं के बीच साझा किया गया डेटा है। इस निर्देशिका तक पहुंच और नीचे कुछ भी, निर्देशिका के समूह द्वारा नियंत्रित किया जाएगा, जो उपयोगकर्ताओं को प्रश्न में जोड़ा जाएगा। जैसे कि मैंने फ़ोल्डर "स्टिकी ग्रुप" chmod g+sसेट बनाया। निर्देशिका में निर्देशिकाओं और फ़ाइलों के साथ एक ट्री संरचना होगी, कुल फ़ाइलों की मात्रा कुछ मिलियन होने की संभावना है। फाइलें काफी छोटी होंगी, मैं 50 एमबी से बड़ी किसी चीज का अनुमान नहीं लगाता।

मेरी समस्या यह है कि फ़ाइल या निर्देशिका का स्वामी अभी भी उपयोगकर्ता है जिसने इसे बनाया है। जैसे, भले ही मुझे उस उपयोगकर्ता को एक्सेस समूह से हटा देना चाहिए, मैं उसकी पहुंच को पूरी तरह से नहीं हटाऊंगा।

इसलिए:

क्या अन्य विकल्प हैं जो यह सुनिश्चित करने में चूक गए हैं कि सभी फाइलों और उप-निर्देशिकाओं का स्वामी एक ही है?

मुझे उम्मीद है कि मैं समय-समय पर पूरी निर्देशिका के माध्यम से एक क्रोन-जॉब के साथ सर्फ कर सकता हूं, लेकिन जो मुझे अनिवार्य रूप से एक बार-पीआर-फाइल कमांड के लिए अक्षम बनाता है।

मुझे INotify का उपयोग करके एक उदाहरण मिला, लेकिन यह मुझे उच्च-रखरखाव के रूप में प्रभावित करता है, क्योंकि इसके लिए स्क्रिप्टिंग की आवश्यकता होती है।

अगर एसीएल मुझे जबरन स्वामित्व में मदद कर सकता है तो मैं इसका पता नहीं लगा सकता।

क्या ऐसा करने का कोई स्मार्ट तरीका है?

मैं चाहता हूं कि एक निर्देशिका होनी चाहिए जिसे एक उपयोगकर्ता के लिए एक समूह जोड़कर साझा किया जा सकता है। इस निर्देशिका में बनाई गई कोई भी चीज़ अपने माता-पिता से अनुमति योजना प्राप्त करती है। अगर मैं जो कोशिश कर रहा हूं, उससे बेहतर तरीका है, मैं सब कान हूं।

Comments

मुझे नहीं लगता कि मुझे समझ में आया कि आप मुझे क्या बताने की कोशिश कर रहे थे। क्या आप विस्तार से समझा सकते हैं?

— मार्टिन नील्सन

एक ही समूह और स्वामित्व वाली सभी फ़ाइलों और उप-निर्देशिकाओं की स्थापना के लिए, उपयोग क्यों नहीं करना है chown -hR owner:group?

— पंड्या

यह संभव है, लेकिन चूंकि हर समय नई फाइलें बनाई जा रही हैं, और हम लाखों में फाइलें बात कर रहे हैं, इसके लिए एक क्रोन नौकरी की आवश्यकता होगी जो पूरी निर्देशिका को समय-समय पर प्रकट करती है। जब तक मुझे कुछ बिंदु याद नहीं आ रहा है?

— मार्टिन नील्सन

के संभावित डुप्लिकेट कैसे एक निर्देशिका में सभी फ़ोल्डर / फ़ाइलों के लिए डिफ़ॉल्ट फ़ाइल अनुमति सेट के लिए?

— पैट्रिक

मैंने वास्तव में इस प्रश्न को बनाने से पहले स्किम्ड किया। यह पता नहीं लगता है कि किसी विशिष्ट उपयोगकर्ता को मालिक को कैसे मजबूर किया जाए।

— मार्टिन नील्सन

Answer 1

डिफ़ॉल्ट स्वामी को "स्वचालित रूप से" सेट करने के लिए एक निर्देशिका की setuidतरह व्यवहार करना होगा setgid। हालाँकि, जब इसे FreeBSD पर कॉन्फ़िगर किया जा सकता है, तो अन्य UNIX और Linux सिस्टम केवल अनदेखा करते हैं u+s। हालांकि आपके मामले में, एक और समाधान हो सकता है।

मैं चाहता हूं कि एक निर्देशिका होनी चाहिए जिसे एक उपयोगकर्ता के लिए एक समूह जोड़कर साझा किया जा सकता है। इस निर्देशिका में बनाई गई कोई भी चीज़ अपने माता-पिता से अनुमति योजना प्राप्त करती है। अगर मैं जो कोशिश कर रहा हूं, उससे बेहतर तरीका है, मैं सब कान हूं।

इसलिए, मूल रूप से, मैं जो देखता हूं, आप समूह तंत्र का उपयोग करके एक निर्देशिका तक पहुंच को नियंत्रित करना चाहते हैं। हालाँकि, इसके लिए आपको संपूर्ण निर्देशिका संरचना में अनुमतियों को प्रतिबंधित करने की आवश्यकता नहीं है। वास्तव में, निर्देशिका --xनिष्पादन बिट सिर्फ वही हो सकता है जिसकी आपको आवश्यकता है। मैं आपको एक उदाहरण देता हूं। ऐसा मानते हुए...

• group_dirनिर्देशिका तक पहुंच को नियंत्रित करने वाला समूह है ourgroup।
• केवल ourgroupसमूह के लोग ही पहुंच सकते हैं group_dir।
• user1और user2से संबंधित हैं ourgroup।
• डिफ़ॉल्ट umask 0022 है।

... निम्नलिखित सेटअप पर विचार करें:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{यहां, मान लें कि प्रत्येक आइटम को उसके स्वामी द्वारा बनाया गया था।}

अब, इस सेटअप में:

• सभी निर्देशिकाओं को सभी के द्वारा स्वतंत्र रूप से ब्राउज़ किया जा सकता है ourgroup। समूह में से कोई भी अंदर कहीं भी फ़ाइलें बना सकता है, ले जा सकता है, हटा सकता है group_dir(लेकिन गहरा नहीं)।
• जो कोई भी अंदर नहीं है ourgroup, उसे अवरुद्ध किया जाएगा group_dir, और इसलिए इसके तहत कुछ भी हेरफेर करने में असमर्थ होगा। उदाहरण के लिए, user3(जो सदस्य नहीं है ourgroup), पढ़ नहीं सकता group_dir/user2_submission/README(भले ही उसके पास r--फ़ाइल पर अनुमति हो)।

हालाँकि, इस मामले में थोड़ी समस्या है: क्योंकि विशिष्ट umask के कारण, उपयोगकर्ताओं द्वारा बनाई गई वस्तुओं को समूह के अन्य सदस्यों द्वारा हेरफेर नहीं किया जा सकता है। यह वह जगह है जहाँ ACLs आते हैं। डिफ़ॉल्ट अनुमतियाँ सेट करके, आप umask मान के बावजूद सब कुछ ठीक कर देंगे:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

यह कॉल सेट:

• rw(x)स्वामी के लिए डिफ़ॉल्ट अनुमतियां
• rw(x)समूह के लिए डिफ़ॉल्ट अनुमतियाँ।
• दूसरों के लिए डिफ़ॉल्ट रूप से कोई अनुमति नहीं। ध्यान दें कि चूंकि अन्यgroup_dir वैसे भी एक्सेस नहीं कर सकते हैं , इसलिए यह वास्तव में कोई फर्क नहीं पड़ता कि उनकी अनुमतियाँ इसके नीचे क्या हैं।

अब, यदि मैं एक आइटम बनाता हूं user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

इस ACL के साथ, हम अपनी पिछली संरचना के पुनर्निर्माण की कोशिश कर सकते हैं:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{यहां फिर से, प्रत्येक आइटम को उसके मालिक द्वारा बनाया गया है।}

इसके अतिरिक्त, यदि आप निर्देशिका का उपयोग करने वालों को थोड़ी अधिक शक्ति / सुरक्षा देना चाहते हैं, तो आप एक चिपचिपा सा विचार करना चाह सकते हैं। उदाहरण के लिए, इसे user1हटाने से रोका जाएगा user2_submission(क्योंकि उसकी -w-अनुमति है group_dir):

$ chmod +t group_dir/

अब, यदि वह निर्देशिका user1को हटाने user2की कोशिश करता है , तो उसे एक प्यारा मिलेगा Operation not permitted। ध्यान दें कि हालांकि यह निर्देशिका संरचना संशोधनों को रोकता है group_dir, इसके नीचे मौजूद फाइलें और निर्देशिकाएं अभी भी सुलभ हैं:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

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

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... इसलिए समूह में किसी को भी अपनी पूरी सबमिशन निर्देशिका उपलब्ध नहीं है।

हालाँकि, जब से आप मूल रूप rwsसे समूह में किसी को भी पूर्ण पहुँच देने को तैयार हैं , मैं मान रहा हूँ कि आप इन उपयोगकर्ताओं पर भरोसा कर रहे हैं, और आप उनसे बहुत से दुर्भावनापूर्ण कार्यों की अपेक्षा नहीं करेंगे।

Comments

क्या ACL डिफ़ॉल्ट अनुमतियों को खत्म कर देगा? उदाहरण के लिए, अगर मैं $ setfacl -dRm u :: r, g :: rwX, o :: 0 group_dir / इसके बजाय, केवल समूह के सदस्यों को फाइलें बनाने की अनुमति देता हूं, तो क्या स्वामी फाइलों को संपादित नहीं कर पाएंगे समूह में? यह महत्वपूर्ण है कि उपयोगकर्ता केवल फाइलों को संपादित कर सकते हैं यदि वे समूह के सदस्य हैं, चाहे मालिक कोई भी हो।

— मार्टिन नील्सन

आपको उसके लिए स्वामी से सभी अनुमतियां निकालने की आवश्यकता नहीं है। समूह फ़ाइल पर लिखने की अनुमति है, तो समूह के सदस्यों को होगा फाइल को संपादित करने में सक्षम हो। मालिक बस "थोड़ा अधिक विशेषाधिकार प्राप्त" होगा। ACL हमेशा डिफ़ॉल्ट अनुमतियों को ओवरराइड नहीं करता है (ACL प्रभावी अनुमतियों के बारे में देखें)।

— जॉन डब्ल्यूएच स्मिथ

मुद्दा यह है कि उपयोगकर्ता के पास कोई निजीकरण नहीं होना चाहिए, केवल समूह होना चाहिए। जब तक वह समूह में है, तब तक सभी इरादों और उद्देश्यों के लिए मालिक को पूरी तरह से वंचित होना चाहिए।

— मार्टिन नील्सन

मूल रूप से, जो कोई भी समूह में नहीं है, वैसे भी वंचित है, क्योंकि वह group_dirपहली बार में प्रवेश करने में सक्षम नहीं होगा , भले ही वह फ़ाइल का मालिक हो या नहीं। एकमात्र वास्तविक "विशेषाधिकार" स्वामी के पास है कि वह अपनी कृतियों की अनुमतियों को बदल सकता है (जो मैंने अपने उत्तर में थोड़ा और विस्तृत किया है)।

— जॉन डब्ल्यूएच स्मिथ

बिलकुल नहीं। group_dirनिर्देशिका के स्वामित्व में है root:ourgroupके साथ -rwxr-x---, जिसका अर्थ है कि केवल रूट और के सदस्यों ourgroupमई यह उपयोग, यानी इसके तहत फाइलों के साथ कुछ भी कर। यदि आपके पास --xकिसी निर्देशिका की अनुमति नहीं है , तो आप इसके भीतर फ़ाइल तक नहीं पहुँच सकते, भले ही आपके पास फ़ाइल की अनुमति हो।

— जॉन डब्ल्यूएच स्मिथ

Answer 2

ऐसा करने का एक स्मार्ट तरीका है। यह सेट-जीआईडी ​​और डिफॉल्ट एक्सेल के संयोजन का उपयोग करता है । जाहिर है, आपको एक एसीएल सक्षम फ़ाइल सिस्टम की आवश्यकता होगी। मान लें कि आपके द्वारा साझा की जाने वाली निर्देशिका चालू है /var/grpdirऔर समूह के सदस्यों को sharingइसे एक्सेस करने में सक्षम होना चाहिए।

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

डिफ़ॉल्ट ACL को डिफ़ॉल्ट ACL के साथ निर्देशिका में बनाई गई उपनिर्देशिकाओं द्वारा विरासत में मिला है। तो इसका मतलब है, इसमें बनाई गई किसी भी फ़ाइल में /var/grpdirयह समूह के sharingलिए निर्देशिका के सेटगिड बिट द्वारा सेट किया जाएगा। इसके अतिरिक्त, यह डिफॉल्ट एसील्स को इनहेरिट करेगा, जो कि डिफॉल्ट लिनेक्स स्टाइल प्रीमियर को ओवरराइड करेगा, क्योंकि हमने विशिष्ट उपयोगकर्ताओं या समूहों के साथ एसीएल को निर्दिष्ट नहीं किया था। इसका मतलब है कि सभी फाइलें स्वामित्व <user>:sharingऔर अनुमतियों के साथ बनाई जाएंगी rw-rw----। निर्देशिकाएँ समान होंगी, सिवाय इसके कि उनके स्वयं के डिफ़ॉल्ट ACL उनके माता-पिता ( /var/grpdir) के लिए भी सेट होंगे, और निश्चित रूप से उपयोगकर्ता और समूह के लिए निष्पादन योग्य बिट्स निर्धारित हैं। यदि आप किसी उपयोगकर्ता को sharingसमूह से हटाते हैं , तो वे निर्देशिका तक नहीं पहुंच पाएंगे (और न ही इसमें कोई भी फ़ाइल, भले ही वे उनके स्वामी हों)।

क्रोनजोब के साथ समय-समय पर अनुमतियों को सही करने के विपरीत, अनुमतियाँ हमेशा सिंक में होती हैं, क्योंकि वे नई बनाई गई फ़ाइलों और निर्देशिकाओं के साथ परमाणु रूप से अपडेट की जाती हैं। यह समाधान हल्का है; कोई डेमॉन आवश्यक नहीं है, और आईओ के लिए कोई स्पाइक नहीं है, जबकि एक झपट्टा में अनुमति को सही करते हुए।

Comments

तो क्या मैं इसे सही तरीके से समझता हूं: यदि आप उपयोगकर्ता या समूह को निर्दिष्ट नहीं करते हैं तो ACL सामान्य फ़ाइल सिस्टम अनुमतियों को अधिलेखित कर देगा?

— मार्टिन नील्सन

नहीं, वे फ़ाइल पर पहले से सेट की गई किसी भी अनुमति को संशोधित नहीं करते हैं। जब किसी निर्देशिका में डिफ़ॉल्ट अनुमति acls सेट होती है, और उस निर्देशिका में एक फ़ाइल या निर्देशिका बनाई जाती है, तो नई फ़ाइल / dir को डिफ़ॉल्ट अनुमतियों को निर्दिष्ट के रूप में दिया जाएगा। निर्देशिका में कॉपी / स्थानांतरित की गई फाइलें अपनी अनुमतियों को बनाए रखती हैं, क्योंकि एकर के सेट होने से पहले निर्देशिका में मौजूद फाइलें कर देती हैं। इसके अलावा, chmod और chown अभी भी सामान्य रूप में इस्तेमाल किया जा सकता है स्वामित्व और अनुमतियों को संशोधित करने के लिए फ़ाइल बनाने के बाद

— sirlark

Answer 3

मुझे ऐसा करने के किसी भी अच्छे तरीके की जानकारी नहीं है। तकनीकी रूप से सबसे साफ तरीका FUSE फाइल सिस्टम होगा जो ऐसा करता है। बेशक, बहुत काम अगर किसी ने अभी तक नहीं किया है।

विकल्प:

1. सांभर का प्रयोग करें। सांबा का force userपैरामीटर है। आप किसी निर्देशिका को स्थानीय रूप से निर्यात कर सकते हैं और उसे स्थानीय स्तर पर माउंट कर सकते हैं। तेजी से पहुंच नहीं बनाता है लेकिन स्वीकार्य हो सकता है क्योंकि केवल लूप बैक नेटवर्किंग शामिल है।

2. FAT32 जैसी नॉन-लिनक्स फाइल सिस्टम का उपयोग करें। इसे माउंट करने के लिए एक निश्चित उपयोगकर्ता के लिए इसे कॉन्फ़िगर किया जाना चाहिए। अभिगम निर्देशिकाओं तक पहुंच की अनुमति होनी चाहिए।

Answer 4

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

उस मामले में, मुझे लगता है कि आपका सबसे अच्छा दांव क्रो -R फ्लैग के साथ क्रोन जॉब है, जैसा कि पंड्या ने उल्लेख किया है। इसे हर मिनट या हर पांच मिनट पर चलाने के लिए क्रोन पर रखें।

यदि आप बता सकते हैं कि आपके उपयोगकर्ता इसका उपयोग कैसे कर रहे हैं, तो कुछ बेहतर समाधान हो सकते हैं।

ACL आपको बारीक अनाज नियंत्रण प्राप्त करने में मदद कर सकता है कि किसको क्या करने की अनुमति है, यह आपके लिए वास्तविक फ़ाइल स्वामित्व को स्वचालित रूप से नहीं बदलेगा। मुझे लगता है कि आपको इस आधार पर अधिक समाधान प्राप्त करने और अपने समाधान का मूल्यांकन / पुन: डिज़ाइन करने की आवश्यकता है।

Answer 5

आप inotify-tools का उपयोग कर सकते हैं और नीचे की तरह एक सरल बैश स्क्रिप्ट लिख सकते हैं । Inotify डायरेक्टरी वेब पर अपनी नजर बनाए रखेगा और कुछ भी करेगा जब भी dir क्रिएशन जैसी घटना वेब डायरेक्टरी के अंदर हो जाएगी। कई आयोजन मौजूद हैं। आप इसे गूगल कर सकते हैं या इस साइट पर देख सकते हैं

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done