सेट्युइड को निर्देशिकाओं पर ध्यान क्यों नहीं दिया जाता है?

19

लिनक्स सिस्टम पर, आप सफलतापूर्वक कर सकते हैं chmod u+s $some_directory, लेकिन नई उपनिर्देशिकाओं और फाइलों के स्वामित्व को मजबूर करने के बजाय युक्त निर्देशिका (और u+sसाथ ही उपनिर्देशिका सेट करना ) के मालिक होने की उम्मीद कर सकते हैं, सिस्टम सिर्फ सेट बिट को अनदेखा करता है। उपनिर्देशिकाएँ और फाइलें उनके बनाने की प्रक्रिया के यूआईडी को जारी रखने के लिए जारी रहती हैं, और उपनिर्देशिकाएं डिफ़ॉल्ट रूप से निर्धारित नहीं होती हैं।

सेट्युइड को निर्देशिकाओं पर ध्यान क्यों नहीं दिया जाता है, और मैं इसे पहचानने के लिए सिस्टम कैसे प्राप्त कर सकता हूं?

linux file-permissions

— ब्लैकलाइट चमक रहा है
स्रोत

मुझे आश्चर्य है कि अगर "नोसिड" माउंट विकल्प इसे प्रभावित कर सकता है।

— हेपेटाइट

विचाराधीन फाइलसिस्टम आरोहित नहीं है - nosuidहालाँकि वहाँ एक और (एक रैमडिस्क /dev/shm) है , जो / है / माउंट किया गया है nosuid, और यह setuidठीक उसी तरह से व्यवहार करता है । 6_9

— ब्लैकलाइट शाइनिंग

1

इन्हें भी देखें: serverfault.com/questions/371541/…

— jjlin

2

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

— माइकबाकॉक

16

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

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

तो, सेतु और फ़ाइल यूआईडी के लिए समान सुविधा क्यों लागू नहीं की गई? खैर, यूआईडी जीआईडी की तुलना में बहुत अधिक बुनियादी है। यदि आप इसे लागू करते हैं, तो अक्सर एक फ़ाइल उस उपयोगकर्ता से संबंधित नहीं होगी जिसने इसे बनाया है! संभवतः उपयोगकर्ता अभी भी फ़ाइल को संशोधित कर सकता है (umask को कुछ समझदार है), लेकिन वे अनुमति बिट्स को बदल नहीं सकते हैं। उस की उपयोगिता को देखने के लिए मुश्किल है।

— इसाक राबिनोविच
स्रोत

मैं इसे लागू करना चाहूंगा, यदि केवल संगति के लिए ... X3 किसी भी मामले में, क्रोनजोब जैसे वर्कअराउंड की समय-समय पर कमी के माध्यम से समय-समय पर स्वामित्व को बदलने और / या फ़ाइल स्वामित्व को मजबूर करने का कोई तरीका है?

— ब्लैकलाइट शाइनिंग

4

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

— इसहाक रैबिनोविच

1

FreeBSD chmod (2) वास्तव में इसकी कुछ चर्चा है, लेकिन केवल इस बात का उल्लेख करता है कि इसका उपयोग आमतौर पर अनिर्दिष्ट "सुरक्षा छेद" के कारण नहीं किया जाना चाहिए। मुझे संदेह है कि अधिकांश अन्य यूनिक्स ने इस सुविधा को नहीं अपनाया, क्योंकि इसमें कुछ उपयोग के मामले हैं, लेकिन यह बहुत उपयोगी नहीं है ।

— jjlin

1

"एक घर निर्देशिका पर सेट" -> की उपयोगिता को देखने के लिए मुश्किल है, इसलिए रूट के रूप में चल रहे प्रावधान स्क्रिप्ट गलती से कुछ चोक करना नहीं भूल सकते हैं?

— ufotds

1

अपने घर निर्देशिका में सुपरसुअर स्क्रिप्ट चलाना वास्तव में एक बुरा विचार है

— आइजैक राबिनोविच

7

मेरा मानना है कि इस सवाल का जवाब "फ़ाइल सस्ता" सुरक्षा मुद्दों पर है, जिसके परिणामस्वरूप अधिकांश आधुनिक यूनिक्स जैसे ओएस "फ़ाइल सस्ता" की अनुमति नहीं देते हैं। "फ़ाइल सस्ता" तब होता है जब एक गैर-सुपरयूज़र उपयोगकर्ता उस उपयोगकर्ता के अलावा किसी अन्य व्यक्ति के लिए फ़ाइल का स्वामित्व बदलता है। यह क्षमता शरारत के लिए कई अवसर प्रदान करती है।

चूंकि फ़ाइल giveaways की अनुमति नहीं है, इसलिए निर्देशिकाओं पर सेट, जो एक ही फ़ंक्शन को किसी अन्य रूप में निष्पादित करेगा, की अनुमति नहीं है, या यदि सेट किया गया है तो उसे अनदेखा कर दिया जाएगा।

व्यवहार को बदलने के लिए, आपको ओएस लाइब्रेरी और उपयोगिताओं को संशोधित करना होगा।

— Yedric
स्रोत

2

इसे लागू करने के लिए एक बहुत अच्छा उपयोग मामला यह है:

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

अगर सेतुनिधि लेकिन निर्देशिका अनुमतियों के लिए निर्धारित बिट की तरह काम करती है तो कुछ इस तरह दिखेगा:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

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

एक अन्य उपयोग मामला बेनामी ftp / http या यहां तक कि sftp / ssh अपलोड के लिए है। अपलोड निर्देशिका पर समूह और GID जड़ होगा और इसलिए स्वामी और UID होगा। अन्य अनुमति होगी -wx। यह हर किसी को अपलोड निर्देशिका में प्रवेश करने की अनुमति देगा, लेकिन वे अपलोड किए जाने के बाद कुछ भी नहीं पढ़ सकते थे और नए बनाए गए सभी फाइलों के मालिक होंगे।

तो GID बिट से मिलान करने के लिए निर्देशिकाओं पर UID कार्यक्षमता को सक्षम करने के लिए दो पूरी तरह से अच्छे और वैध उपयोग के मामले हैं।

स्टीवन मर्कुरियो

— user297422
स्रोत

1

यह उस प्रश्न को संबोधित नहीं करता है जो पूछा गया था।

— केविन पेंको

2

@ क्वीनपैंको नहीं, यह मेरे सवाल का जवाब नहीं देता है। यह साइट के लिए ऑफ-टॉपिक भी हो सकता है ("क्या उपयोग मामला है <nonexistent feature X>?")। हालाँकि, यह मेरे प्रश्न से संबंधित है, और मैं, प्रश्नकर्ता के रूप में, इसे उपयोगी मानता हूँ।

— ब्लैकलाइट चमक रहा है

0

पार्टी के लिए थोड़ा देर से, लेकिन अगर भविष्य में पाठक इस पर ठोकर खाते हैं;) जैसा कि दूसरों द्वारा कहा गया है, एक मानक ओएस-एक्स फाइलसिस्टम पर निर्देशिका के लिए सेटयूआईडी को अनदेखा किया जाता है - और इसके आस-पास एक आसान तरीका नहीं लगता है ( mount -o.... या क्या नहीं)। जैसा कि अक्सर होता है, मैन पेज वास्तव में ओएस-एक्स के व्यवहार का अनुपालन नहीं करता है, जिसका शाब्दिक अर्थ है:

4000 (सेट-यूज़र-आईडी-ऑन-एक्ज़ीक्यूशन बिट) [...] सेट-यूज़र-आईडी बिट सेट के साथ डायरेक्ट्रीज़ सभी फाइलों और उप-निर्देशिकाओं को उनके द्वारा तैयार की जाएंगी जो डायरेक्ट्री मालिक के पास होंगी और नहीं बनाने की प्रक्रिया के uid [...]

लेकिन यह मूल स्वामित्व को छोड़े बिना उसी प्रभाव को प्राप्त करने की संभावना को भी सूचीबद्ध करता है। लिनक्स समान प्रभावों के लिए '[g /] सेटफेकल्स का उपयोग करता है (वे पहली नज़र में वास्तव में दिखाई नहीं देने वाली अनुमतियाँ हैं, इसलिए कभी-कभी उपद्रव हो सकता है)।

'मैं कैसे समान प्रभाव प्राप्त कर सकता हूं' के रूप में, पूरे मैन पेज पढ़ें और इसके साथ फिडेल करें:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

आप के माध्यम से जाँच कर सकते हैं

ls -le

अगर सब ठीक लग रहा है। आगे के विकल्पों में विशिष्ट पदों पर नियम सम्मिलित करना, विशिष्ट नियमों को हटाना या प्रतिस्थापित करना शामिल है। यहां दो उल्लेखनीय विकल्प " file_inheritऔर directory_inherit" नियमों को एक नई निर्देशिका / फ़ाइल में संलग्न करने की अनुमति देते हैं।

मैं वास्तव में सेटयूआईडी का उपयोग करने का शौकीन नहीं हूं, लेकिन सेटजीआईडी उन फाइलों पर बहुत काम आती है, जहां बस 'मुख्य' समूह सेट करने से काम नहीं चलता है या ग्राहकों के पास ग्रुप राइटिंग को खारिज करने वाले फिल्ममेक होते हैं। यह द्वारा हल किया जाएगा:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

— कीथ
स्रोत

स्टैक एक्सचेंज में आपका स्वागत है! यह एक अच्छा जवाब है, हालांकि जैसा कि यह लिनक्स डिस्ट्रोस के बजाय ओएस एक्स से संबंधित है (जो, जैसा कि आपने उल्लेख किया है, एक अलग एसीएल सिस्टम का उपयोग करें), यह यहां उतना प्रासंगिक नहीं लगता है। यह निश्चित रूप से एक सवाल पर अच्छा होगा कि ओएस एक्स सम्मान सेट्युइड निर्देशिका कैसे करें ; शायद आपको एक पोस्ट करना चाहिए ?

— ब्लैकलाइट शाइनिंग

वैसे, आप chownवास्तव में ओएस एक्स के मैनुअल पेज से बाहर निकले बिट बहुत महत्वपूर्ण लगता है! यदि "...] यदि अंतर्निहित फ़ाइल सिस्टम इस सुविधा का समर्थन करता है: chmod (2) और suiddir विकल्प को (8) माउंट करने के लिए देखें।" मैंने वास्तव में पहले कभी उस बिट पर ध्यान नहीं दिया था। यदि HFS लागू होता है suiddir, तो आप वास्तव में एक सामान्य OS X सिस्टम पर ऐसा कर सकते हैं।

— ब्लैकलाइट शाइनिंग

(और OS X ACLs सिर्फ "पहली नज़र में नहीं दिख रहे हैं" जैसा कि लिनक्स ACLs हैं।)

— ब्लैकलाइट शाइनिंग

0

खैर, यह मानक का सम्मान करना चाहिए। मैं sftp के साथ काफी कुछ स्थलों पर सोच सकता हूं-केवल यह कि मुझे बहुत परेशानी से बचाएंगे, दोनों के साथ acl और acl-mask-जो कि sshd करता है, और रीसेट करता है कि मुझे उस मास्क को करना चाहिए।

डिफ़ॉल्ट रूप से सुरक्षा काफी उपयोगी है, लेकिन यदि आप इसे एक विकल्प नहीं बनाते हैं, तो आप बस एक विंगमार्ट बना रहे हैं।

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

किसी भी तरह से, यह लिनक्स के रूप में अब चला जाता है, इसलिए उन लोगों के आसपास काम करने के लिए बस एसईसीएल का उपयोग करें।

— user576407
स्रोत

-1

Http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories के अनुसार , Setuid बिट को UNIX और Linux सिस्टम दोनों पर निर्देशिकाओं के लिए अनदेखा किया गया है। हालाँकि, यह संभव है जैसा कि आप FreeBSD पर उम्मीद करते हैं।

— mikebabcock
स्रोत

सहायक नहीं है - मैंने पूछा कि setuidनिर्देशिकाओं के लिए उपेक्षा क्यों की गई थी और यदि यह लिनक्स पर मान्यता प्राप्त करना संभव था।

— ब्लैकलाइट शाइनिंग

यह स्पष्ट प्रतीत होता है कि लिनक्स पर इसकी अनदेखी की गई क्योंकि यूनिक्स पर इसकी अनदेखी की गई, जो लिनक्स के लिए वास्तविक * निक्स के साथ फिट होने के लिए सही व्यवहार करता है। प्रश्न में लेख पढ़ने के लिए स्वतंत्र महसूस करें। 2004 से greenend.org.uk/rjk/tech/perms.html पर एक ही उत्तर , serverfault.com/questions/371541/…

— mikebabcock

तो यूनिक्स पर इसकी अनदेखी क्यों की गई है?

— आइजैक राबिनोविच

@IsaacRabinovitch के बाद से ब्लैकलाइट ने यह स्पष्ट किया कि यह सवाल लिनक्स के बारे में है, यह प्रासंगिक नहीं है [गाल में जीभ] लेकिन मुझे इसके बस अपरिभाषित व्यवहार पर संदेह है जहां कई यूनिक्स ने इसके साथ अलग-अलग चीजें कीं और कुछ भी करना सुरक्षित नहीं है।

— माइकबाकॉक

प्रश्न / है / टैग किया गया है linux, हां, लेकिन इसका मतलब यह नहीं है कि मैं एक अस्पष्ट पसंद करूंगा "यह इस तरह से किया गया है क्योंकि अन्य प्रणालियां इसे इस तरह से करती हैं" एक उत्तर के उत्तर में बताया गया है कि यह बताता है कि अन्य प्रणालियों पर ऐसा क्यों किया जाता है। (शायद linuxटैग को बस हटा दिया जाना चाहिए?)

— ब्लैकलाइट शाइनिंग