समूह पर chmod (1) ACL मास्क को क्यों प्रभावित करता है?

Question

मैं इस यूनिक्स व्यवहार को समझने की कोशिश कर रहा हूं (जो कि मैं Ubuntu 11.10 पर परीक्षण कर रहा हूं):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

ध्यान दें कि chmod (1) कमांड ने ACL मास्क को अपडेट किया है। ऐसा क्यों होता है?

SunOS मैनपेज निम्नलिखित में क्या कहना है:

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

मैं पूछता हूं क्योंकि यह मेरे लिए सुविधाजनक होगा यदि चामोद (1) में यह व्यवहार नहीं था। मुझे उम्मीद है कि यह समझने से कि यह क्या करता है, मैं बेहतर डिज़ाइन कर सकता हूं कि मैंने फाइलसिस्टम अनुमतियों को कैसे सेट किया।

Comments

अब मुझे आश्चर्य है कि अगर मुझे unix.stackexchange.com पर यह पूछना चाहिए था। सही साइट चुनने की कोशिश करना हमेशा चुनौतीपूर्ण होता है।

— माइकल क्रोपट

Answer 1

यदि आपके पास यह व्यवहार नहीं है तो यह आपके लिए सुविधाजनक नहीं होगा chmod()।

यह अत्यधिक असुविधाजनक होगा, क्योंकि लोग जिन चीजों की परंपरागत रूप से यूनिक्स पर काम करने की उम्मीद करते हैं, वे टूट जाएंगे। यह व्यवहार आपको अच्छी तरह से परोसता है, क्या आपने लेकिन इसे जान लिया है।

यह शर्म की बात है कि IEEE 1003.1e कभी भी एक मानक नहीं बन गया और 1998 में वापस ले लिया गया। व्यवहार में, चौदह साल पर, यह एक मानक है जो ऑपरेटिंग सिस्टम की एक विस्तृत श्रृंखला - लिनक्स से फ्रीबीएसडी से सोलारिस तक - वास्तव में लागू होता है।

IEEE 1003.1e कार्य ड्राफ्ट # 17 दिलचस्प पढ़ने के लिए बनाता है, और मैं इसकी सलाह देता हूं। परिशिष्ट B .3 23.3 में, कार्यसमूह कुछ जटिल तरीके के लिए एक विस्तृत, आठ पेज का औचित्य प्रदान करता है, जो POSIX ACLs पुराने S_IRWXGसमूह की अनुमति झंडे के संबंध में काम करता है । (यह ध्यान देने योग्य है कि टीआरयूएसआईएक्स लोगों ने दस साल पहले एक ही विश्लेषण प्रदान किया था।) मैं यह सब यहां कॉपी नहीं करने जा रहा हूं। विवरण के लिए मसौदा मानक में तर्क पढ़ें। यहाँ एक बहुत ही संक्षिप्त विवरण है :

• सनोस मैनुअल गलत है। इसे पढ़ना चाहिए

  यदि आप chmod(1)ACL प्रविष्टियों वाली फ़ाइल पर फ़ाइल समूह स्वामी अनुमतियाँ बदलने के लिए आदेश का उपयोग करते हैं, तो फ़ाइल समूह स्वामी अनुमतियाँ या ACL मास्क नई अनुमतियों में परिवर्तित हो जाती हैं।

  यह वह व्यवहार है जिसे आप अपने प्रश्न में वर्तमान मैनुअल पेज के अनुसार कहने के बावजूद देख सकते हैं । यह POSIX मानक के मसौदे द्वारा निर्दिष्ट व्यवहार भी है। यदि एक्सेस-कंट्रोल एंट्री के CLASS_OBJलिए Sun (Sun's और TRUSIX की शब्दावली ACL_MASK) मौजूद है, तो समूह chmod()इसे सेट करता है, अन्यथा वे GROUP_OBJएक्सेस-कंट्रोल एंट्री सेट करते हैं ।

• यदि ऐसा नहीं होता, तो अनुप्रयोग जो `चामोद ()` के साथ कई मानक चीजें करते थे, उम्मीद करते हैं कि यह `चामोद ()` के रूप में काम करने के लिए परंपरागत रूप से पुराने गैर-एसीएल यूनिक्स पर काम कर चुके हैं, या तो सुरक्षा छेदों को छोड़ देंगे या क्या देखेंगे उन्हें लगता है कि सुरक्षा छेद ख़राब हो सकते हैं:

  • पारंपरिक यूनिक्स अनुप्रयोगों के साथ किसी फ़ाइल, पाइप, डिवाइस या निर्देशिका नाम की सभी पहुंच से इनकार करने में सक्षम होने की उम्मीद है chmod(…,000)। ACL की उपस्थिति में, यह केवल सभी उपयोगकर्ता और समूह अनुमतियों को बंद कर देता है यदि पुराने S_IRWXGनक्शे CLASS_OBJ। इसके बिना, पुरानी फ़ाइल अनुमतियों को सेट करने से 000किसी भी USERया GROUPप्रविष्टियों को प्रभावित नहीं किया जा सकता है और अन्य उपयोगकर्ता आश्चर्यजनक रूप से, अभी भी ऑब्जेक्ट तक पहुंच पाएंगे।

    अस्थायी रूप से फ़ाइल की अनुमति बिट्स को बिना किसी एक्सेस के chmod 000बदलने और फिर उन्हें फिर से बदलने के लिए एक पुरानी फाइल लॉकिंग मैकेनिज्म थी, जिसका इस्तेमाल यूनिक्स ने सलाहकार लॉकिंग मैकेनिज्म प्राप्त करने से पहले किया था, जैसा कि आप देख सकते हैं - लोग आज भी उपयोग करते हैं ।

  • पारंपरिक यूनिक्स लिपियों chmod go-rwxसे केवल उस वस्तु के मालिक के पास चलने और समाप्त होने की उम्मीद होती है जो वस्तु तक पहुंचने में सक्षम हो। फिर - जैसा कि आप देख सकते हैं - यह अभी भी बारह साल बाद प्राप्त ज्ञान है । और फिर, यह जब तक पुराने काम नहीं करता है S_IRWXGके लिए नक्शे CLASS_OBJयदि वह मौजूद है, क्योंकि अन्यथा कि chmodआदेश किसी भी बंद नहीं होगा USERया GROUPअभिगम नियंत्रण प्रविष्टियों, स्वामी और गैर मालिक कुछ है कि के लिए उपयोग को बनाए रखना समूहों के अलावा अन्य उपयोगकर्ताओं के लिए अग्रणी है केवल स्वामी के लिए सुलभ होने की उम्मीद है ।

  • एक प्रणाली जहां अनुमति बिट अन्यथा andACL के साथ से अलग और एड थे rwxrwxrwx, ज्यादातर मामलों में फाइल की अनुमति के झंडे की आवश्यकता होगी , जो कई यूनिक्स अनुप्रयोगों में से बिल्ली को भ्रमित करेगा जो शिकायत करते हैं कि जब वे देखते हैं कि वे विश्व-योग्य हैं सामान।

    ऐसी प्रणाली जहां orACL के साथ अनुमति बिट अन्यथा से अलग थे और chmod(…,000)पहले बताई गई समस्या होगी ।

आगे की पढाई

• विनफ्रेड ट्रुपर (1999-02-28)। Posix.1e के बारे में सारांश
• IEEE कंप्यूटर सोसाइटी की पोर्टेबल अनुप्रयोग मानक समिति (अक्टूबर 1997)। सूचना प्रौद्योगिकी के लिए ड्राफ्ट मानक-पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस (POSIX) -पार्ट 1: सिस्टम एप्लिकेशन प्रोग्राम इंटरफ़ेस (API) - संशोधन #: संरक्षण, लेखा परीक्षा और नियंत्रण इंटरफेस [सी भाषा] IEEE 1003.1e। ड्राफ्ट 17।
• क्रेग रुबिन (1989-08-18)। यूनिक्स प्रणाली के लिए एक्सेस कंट्रोल लिस्ट सुविधाओं का चयन करने के लिए तर्क । NCSC-TG-020-ए। DIANE प्रकाशन। आईएसबीएन 9780788105548

Comments

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

— माइकल क्रोपट

@hopeseekr आप हमेशा लिनक्स, जीएनयू उपयोगिताओं के 100 के दशक और सॉफ्टवेयर के तीसरे-पक्ष के टुकड़े के लिए कांटा कर सकते हैं ताकि वे S_IRWXGअब अनुमति का उपयोग न करें । जब आपका काम हो जाए तो मुझे फोन करना।

— तोबिया

Answer 2

यह व्यवहार केवल POSIX ACL प्रविष्टियों पर लागू होता है। इसका कारण यह है कि यदि आपके पास एक फ़ोल्डर है और उस फ़ोल्डर के अंदर एक फ़ाइल मौजूद है, तो आप rwx (उदाहरण के लिए) फ़ोल्डर और फ़ाइल के रूप में acl कर सकते हैं। यदि फ़ाइल की समूह अनुमतियाँ rw- हैं (जो कि वे एक विशिष्ट परिदृश्य के रूप में हो सकती हैं) तो मास्क इस प्रकार acl को rw की प्रभावी अनुमति देता है- भले ही ACL स्पष्ट रूप से rwx को दर्शाता हो।

दूसरी ओर, निर्देशिका जो लगभग हमेशा + x है प्रभावी ACL मुखौटा अनुमतियाँ भी + x की अनुमति है।

सारांश में, इस मास्क का उपयोग मूल रूप से POSIX ACL सेट के लिए फ़ाइलों और फ़ोल्डरों के बीच अंतर करने के लिए किया जाता है ताकि एक फ़ाइल निष्पादन योग्य न हो जाए जब यह सामान्य रूप से नहीं होना चाहिए।

Comments

यदि कोई इसे पढ़ता है, तो यह उत्तर पूरी तरह से गलत है।

— pogetz