एक फ़ाइल दो उपयोगकर्ताओं से संबंधित है। कैसे? कड़ी जोड़ने में विफल रहता है

32

दो setuid प्रोग्राम, /usr/bin/barऔर /usr/bin/baz, एक एकल कॉन्फ़िगरेशन फ़ाइल साझा करें foo। कॉन्फ़िगरेशन फ़ाइल का मोड 0640संवेदनशील जानकारी रखने के लिए है। एक कार्यक्रम के रूप में चलता है bar:bar(जो उपयोगकर्ता बार, समूह बार के रूप में है ); अन्य के रूप में baz:baz। उपयोगकर्ताओं को बदलना एक विकल्प नहीं है, और यहां तक कि समूहों को बदलना बेहतर नहीं होगा।

मैं के रूप में /etc/bar/fooऔर एकल विन्यास फाइल को कड़ी से कड़ी करना चाहता हूं /etc/baz/foo। हालाँकि, यह विफल रहता है क्योंकि फ़ाइल को, जहाँ तक मुझे पता है, या तो या से संबंधित root:barहै root:baz।

संभावित समाधान: एक नया समूह बनाएं barbazजिसके सदस्य हैं barऔर baz। के fooहोते हैं root:barbaz।

यह मेरे लिए एक बहुत भारी हाथ समाधान की तरह लग रहा है। क्या fooदो कार्यक्रमों के बीच कॉन्फ़िगरेशन फ़ाइल साझा करने का कोई सरल, सरल तरीका नहीं है ?

अभी के लिए, मैं फ़ाइल की दो समान प्रतियाँ बना रहा हूँ। यह काम करता है, लेकिन स्पष्ट रूप से गलत है। क्या सही होगा?

जानकारी के लिए: मेरे पास यूनिक्स समूहों के साथ बहुत कम अनुभव है और कोई भी सेटगिड (2) के साथ नहीं है।

permissions hard-link

— THB
स्रोत

सवाल आम तौर पर चरणबद्ध है। मेरे विशिष्ट मामले में, दो प्रोग्राम Exim4 और Dovecot, मेल-हैंडलिंग प्रोग्राम हैं जो पासवर्ड और TLS प्रमाणपत्र साझा कर सकते हैं।

— thb

8

इसके लिए उबंटू (और मुझे लगता है कि डेबियन) समाधान ssl-certसमूह है, जो आपके barbazसमूह से बहुत अधिक है । मानक ssl-certसमूह के स्वामित्व वाली सभी निजी कुंजियों को सेट करना है , और उन कार्यक्रमों से जुड़े यूआईडी को उस समूह तक पहुंचाना है।

— अब्लीग

1

@ बाल: दिलचस्प है। मेरा सिस्टम डेबियन 8 जेसी है। जाहिरा तौर पर, वहाँ एक पैकेज मौजूद है ssl-certजिसकी स्थापना के बाद स्क्रिप्ट लिपि का निर्माण करती है, जिसके समूह को आप बोलते हैं। मैं अनजान बन चुका था ssl-cert। Apache2 (मेरे होस्ट पर स्थापित) अनुशंसा करता है ssl-cert । विभिन्न एक्ज़िम और डवकोट पैकेज नहीं हैं, लेकिन पोस्टफिक्स (मेरे होस्ट पर स्थापित नहीं) पर निर्भर करता है ssl-cert। अपाचे के कारण, मेरे होस्ट में एक ssl- प्रमाणित समूह है, लेकिन इस समूह में अभी तक कोई सदस्य नहीं है। सलाह के लिए धन्यवाद।

— thb

5

कार्यक्रमों को निर्धारित करें, न कि निर्धारित। सेतुविद कार्यक्रम एक बुरा विचार है क्योंकि अगर वे समझौता कर रहे हैं, तो बाइनरी को बदला जा सकता है, ट्रोजन हॉर्स बना सकते हैं। (अपवाद: setuid रूट, क्योंकि आपके पास कोई विकल्प नहीं है।)

— गाइल्स का SO- बुराई करना बंद करें '

1

क्या wiki.dovecot.org/HowTo/EximAndDovecotSASL आपकी विशिष्ट स्थिति को हल करता है?

— MvG

50

आप ACL का उपयोग कर सकते हैं ताकि फ़ाइल को दोनों समूहों में लोगों द्वारा पढ़ा जा सके।

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

अब दोनों barऔर bazसमूह फाइल को पढ़ सकते हैं।

उदाहरण के लिए, यहाँ एक फ़ाइल है जिसका बिन: मोड 640 के साथ बिन है।

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

इसका +मतलब है कि एक एसीएल सेट है, तो आइए इसे देखें।

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

हम लाइन देख सकते हैं group:sweh:r--: इसका मतलब है कि समूह के लोग swehइसे पढ़ सकते हैं।

अरे, वह मैं हूं!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

और हां, मैं फाइल पढ़ सकता हूं।

$ cat foo
data

— स्टीफन हैरिस
स्रोत

23

आप इन कथनों पर पुनर्विचार करना चाहते हैं:

संभावित समाधान: एक नया समूह बार्बाज़ बनाएँ जिसके सदस्य हैं barऔर baz। के fooहोते हैं root:barbaz।

यह मेरे लिए एक बहुत भारी हाथ समाधान की तरह लग रहा है। क्या fooदो कार्यक्रमों के बीच कॉन्फ़िगरेशन फ़ाइल साझा करने का कोई सरल, सरल तरीका नहीं है ?

एक नया समूह बनाने के लिए यह भारी-भरकम क्यों है? ऐसा करने से ACL पर निम्नलिखित लाभ होते हैं:

हालाँकि आपने इसे कमांड के साथ एक काल्पनिक के रूप में चित्रित किया है /usr/bin/barऔर /usr/bin/baz, यह प्रासंगिक है कि ये दोनों प्रोग्राम एक कॉन्फ़िगरेशन फ़ाइल साझा कर सकते हैं। इससे पता चलता है कि कार्यक्रम स्वाभाविक रूप से संबंधित हैं। उनके लिए एक नया समूह बनाना एक ऐसे रिश्ते का वर्णन करता है जो वास्तव में मौजूद है और उसे व्यवहार को ट्रिगर करना चाहिए (जैसे कि सामान्य कॉन्फ़िगरेशन फ़ाइल पढ़ने की अनुमति)।
समूहों के माध्यम से इस समस्या को हल करना हर यूनिक्स के लिए पोर्टेबल है , जिसका अर्थ है कि आप एक ही तंत्र पर भरोसा कर सकते हैं, किसी भी यूनिक्स या यूनिक्स जैसी प्रणाली पर बिल्कुल उसी तरह से काम कर सकते हैं। ACL कहीं अधिक जटिल हैं और पोर्टेबिलिटी एक समस्या हो सकती है।

व्यक्तिगत रूप से मैं ACLs को यहाँ के भारी-भरकम समाधान के रूप में देखता हूं, और समूहों को सरल, पारंपरिक यूनिक्स तरीके से।

— user9999999
स्रोत

16

मुझे लगता है कि यह एक्सेस कंट्रोल लिस्ट (ACL) के लिए एक विशिष्ट उपयोग होगा। दोनों उपयोगकर्ताओं (या समूहों) को कॉन्फ़िगर-फाइल के ACL में जोड़ें:

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo

$ setfacl -m उपयोगकर्ता: बार: rw- / etc / foo # उपयोगकर्ता बार को पढ़ने और लिखने की अनुमति देता है
$ setfacl -m उपयोगकर्ता: baz: rw- / etc / foo # उपयोगकर्ता baz को पढ़ने और लिखने के लिए अनुमति देता है

आपको पहले acl-package स्थापित करना पड़ सकता है।

— बाड कोपरपुड
स्रोत

3

फ़ाइल का मोड बनाएं 0660(या भले 0440ही लेखन की आवश्यकता न हो) और स्वामित्व bar:baz। फिर एक प्रक्रिया उपयोगकर्ता अनुमतियों के लिए फ़ाइल धन्यवाद तक पहुंच सकती है, दूसरा समूह अनुमतियों के लिए धन्यवाद। यह फ़ाइल सिस्टम पर भी काम करता है जहाँ ACLs नहीं है।

— MVG
स्रोत

2

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

"नया" "क्लाउड" तरीका एक कॉन्फ़िगरेशन प्रबंधन प्रणाली (जैसे शेफ , कठपुतली , या ansible ) द्वारा नियंत्रित सभी विन्यास है । तब यह मायने नहीं रखता कि आपके पास सर्वर पर दो अलग-अलग लेकिन समान फाइलें हैं, क्योंकि दोनों कॉन्फ़िगरेशन प्रबंधन प्रणाली से एकल फ़ाइल की एक प्रति हैं।

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

(रिकॉर्ड के लिए, चूंकि आप कॉन्फ़िगरेशन प्रबंधन का उपयोग नहीं कर रहे हैं, मैं @ डॉजी के उत्तर में समूह प्रणाली के साथ जाऊंगा)।

— Law29
स्रोत