उपयोगकर्ता को केवल एक डायरेक्टरी में पढ़ने / लिखने की सुविधा दें

Question

मैं एक सर्वर चला रहा हूं, और मुझे किसी विशेष उपयोगकर्ता को किसी विशेष उपयोगकर्ता को पढ़ने / लिखने की सुविधा देने की आवश्यकता है। मैंने निम्नलिखित कोशिश की है:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

ऊपर काम करने के लिए लगता है, हालांकि यह उपयोगकर्ता को केवल शेष सर्वर तक पहुंच प्रदान करता है।

मैं अनुमतियाँ कैसे सेट कर सकता हूं ताकि उपयोगकर्ता केवल एक विशेष फ़ोल्डर में पढ़ और लिख सके? उपयोगकर्ता को भी प्रोग्राम चलाने में सक्षम होना चाहिए mysql।

Comments

संक्षिप्त उत्तर: एक चुरोट का उपयोग करें।

— क्रिस डाउन

@ क्रिस एक जवाब में उस पर विस्तृत देखभाल करने के लिए? मनीष और मैं इससे जूझ रहे हैं और यह काम नहीं कर सकता।

— पूर्ववत करें

mysqlकार्यक्रम कहाँ स्थित होगा? उपयोगकर्ता को इसे पढ़ने में सक्षम होना चाहिए, और सभी पुस्तकालयों और डेटा फ़ाइलों को इसकी आवश्यकता है।

— गिलेस एसओ- बुराई को रोकना 'नोव

@ गिल्स हम्म। यह एक मानक mysql है apt-get से स्थापित करें, जहां तक ​​मैं बता सकता हूं (मेरी प्रणाली नहीं है, यह पूर्ववत है)।

— मनीषीर्थ

Answer 1

नकारात्मक ACLs

आप एक्सेस कंट्रोल लिस्ट सेट करके किसी उपयोगकर्ता को फाइल सिस्टम के कुछ हिस्सों को एक्सेस करने से रोक सकते हैं । उदाहरण के लिए, यह सुनिश्चित करने के लिए कि उपयोगकर्ता abcdकिसी भी फ़ाइल के नीचे नहीं पहुँच सकता /home:

setfacl -m user:abcd:0 /home

यह दृष्टिकोण सरल है, लेकिन आपको हर उस चीज तक पहुंच को ब्लॉक करना याद रखना चाहिए, जिसे आप एक्सेस करने में abcdसक्षम नहीं होना चाहते हैं ।

chroot

जो abcdदेख सकता है, उस पर सकारात्मक नियंत्रण पाने के लिए, एक क्रोकेट सेट करें , अर्थात उपयोगकर्ता को फाइलसिस्टम के एक उपप्रकार तक सीमित करें।

आपको उन सभी फ़ाइलों को बनाने की आवश्यकता है जो उपयोगकर्ता को चाहिए (जैसे mysqlऔर यदि आप उपयोगकर्ता को चलाने के लिए सक्षम होना चाहते हैं mysql) चेरोट के तहत। कहो चुरोट का रास्ता है /home/restricted/abcd; mysqlकार्यक्रम उपलब्ध के तहत होने की जरूरत है /home/restricted/abcd। चेरोट के बाहर इंगित करने वाला एक प्रतीकात्मक लिंक अच्छा नहीं है क्योंकि प्रतीकात्मक लिंक लुकिंग चेरोट जेल से प्रभावित होता है। लिनक्स के तहत, आप बाइंड माउंट का अच्छा उपयोग कर सकते हैं:

mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr

आप फ़ाइलों की प्रतिलिपि भी बना सकते हैं (लेकिन तब आपको ध्यान रखना होगा कि वे अद्यतित हैं)।

उपयोगकर्ता को चेरोट तक सीमित करने के लिए, एक ChrootDirectoryनिर्देश जोड़ें /etc/sshd_config।

Match User abcd
    ChrootDirectory /home/restricted/abcd

आप इसका परीक्षण कर सकते हैं: chroot --userspec=abcd /home/restricted/abcd/ /bin/bash

सुरक्षा ढांचा

आप सुरक्षा ढांचे जैसे कि SELinux या AppArmor का भी उपयोग कर सकते हैं। दोनों ही मामलों में, आपको यह सुनिश्चित करने के लिए कि आपको कोई छेद नहीं छोड़ना है, एक बहुत ही नाजुक विन्यास लिखना होगा।

Comments

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

— कासिम

@Qimim की आवश्यकता है कि सभी फ़ाइलों की अपनी अनुमतियाँ और स्वामित्व सेट वांछित हैं। ऐसी बहुत सी चीजें हैं जो गलत हो सकती हैं (फाइलें कहीं से कॉपी की गई हैं या संग्रह से निकाली गई उनकी अनुमतियों के साथ संग्रहित हैं, फाइलें जिन्हें किसी अन्य समूह से संबंधित होने की जरूरत है, फाइलें जो समूह-पठनीय नहीं होनी चाहिए, जो उपयोगकर्ता गलती करते हैं या कर सकते हैं ' टी को यह सुनिश्चित करने के लिए परेशान किया जाना चाहिए कि समूह पहुंच वांछित है ...) कि समूह वास्तव में इस समस्या को हल नहीं करते हैं।

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

मेरा मतलब है कि मैं नहीं देखता कि कैसे फाइलों की अपनी अनुमति होती अगर निर्देशिका पर समूह अनुमतियाँ इस तरह से सेट की जातीं जहाँ कोई उपयोगकर्ता निर्देशिका में "सीडी" या निर्देशिका को "ls" नहीं कर सकता था।

— कासिम

@ क्यूसिम हर फ़ाइल के तहत /var/www/allowfolderऔर उसकी उपनिर्देशिकाएँ सुलभ होनी चाहिए, न कि केवल /var/www/allowfolderस्वयं। और इसके विपरीत अन्य फाइलें सुलभ नहीं होनी चाहिए। वास्तव में फ़ाइल अनुमतियों और ACL पर आधारित एक समाधान पूरी तरह से आवश्यकताओं को पूरा नहीं कर सकता है: यह कम से कम उपयोगकर्ता को यह परीक्षण करने की अनुमति देगा कि क्या कोई दिया गया नाम मौजूद है /var/www, क्योंकि उन्हें /var/wwwएक्सेस करने के लिए x अनुमति की आवश्यकता है /var/www/allowfolder।

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

ओह ठीक है, लेकिन अगर हम / var निर्देशिका को इसमें से निकाल देते हैं और कहते हैं कि हम सामान्य निर्देशिका के बारे में / होम / उपयोगकर्ता निर्देशिका में बात कर रहे हैं?

— कासिम

Answer 2

आपको उपयोग करना चाहिए chroot। chrootआदेश रूट निर्देशिका है कि सभी बच्चे प्रक्रियाओं को देखने बदल जाता है। मैं यह दिखाने के लिए एक उदाहरण दूंगा कि यह कैसे काम करता है।

यह मौके पर लिखा गया था; मैं वास्तव में अभी UNIX मशीन के सामने नहीं हूँ। इस उदाहरण में, वहाँ एक निर्देशिका कहा जाता है dirतीन फाइलों के साथ: a, b, c, और ls। पहले तीन नियमित फाइलें हैं। lsअसली lsबाइनरी के लिए एक हार्डलिंक है ताकि हम चेरोट में फ़ाइलों को सूचीबद्ध कर सकें।

मैं जा रहा हूँ chrootमें dir। (ध्यान दें कि मैं मूल निर्देशिका में कुछ निर्देशिकाओं को भूल रहा हूं।)

यहाँ सेटअप है, शेल आउटपुट फॉर्म में:

$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var

अब मैं हूँ chrootमें dir। /bin/bashतर्क चुनता है की प्रक्रिया नए रूट निर्देशिका के साथ चलाने की जानी चाहिए। यह करने के लिए चूक /bin/sh।

$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/

अब हम इससे बाहर निकलते हैं chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

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

एक फ़ाइल के लिए एक हार्डलिंक एक के अंदर काम करना जारी रखेगा chroot, भले ही उस फ़ाइल को अन्य माध्यमों से एक्सेस नहीं किया जा सकता है (यह काम करता है क्योंकि हार्डलिंक इनकोड को इंगित करता है, पथ नहीं)। इसलिए, उपयोगकर्ता को उदाहरण के लिए mysqlकमांड को एक्सेस करने की अनुमति देने के लिए , आप निष्पादित करेंगे:

ln /usr/bin/mysql /path/to/chroot/target

Comments

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

— मनिशिथर्थ

असल में, क्या अन्य उपयोगकर्ताओं की पहुंच को प्रभावित किए बिना उपयोगकर्ता को शेष एफएस तक पहुंच खोने का कोई तरीका है (chmod के माध्यम से)?

— मनिशिथर्थ

@Manishearth के साथ कोई सरल तरीका नहीं है chmod। जब आप कहते हैं "कमांड चलाना आसान नहीं होगा ... उन तक पहुंच न खोएं", यह कमांड है chroot। यदि आप समझाते हैं कि "संपूर्ण चिरोट वातावरण" से आपका क्या मतलब है, या यह समस्या क्यों होगी, तो शायद मैं बेहतर समझ पाऊंगा। (ध्यान दें कि आप एक oneliner साथ सभी निष्पादन योग्य पर पहुंच सकते हैं कि: ln /bin/* /path/to/chroot/target)

— strugee

@ यदि मेरा उदाहरण समझ में नहीं आया तो मैं आपको chrootअपने साथ खेलने के लिए प्रोत्साहित करूंगा या मुझे बताऊंगा कि क्या मतलब नहीं था। और भी बेहतर, दोनों करें। (और

— मैनपावर

@ यदि यह उत्तर आपको उत्तर की ओर ले जाने में पर्याप्त मदद करता है, तो आपको इसे स्वीकार करने पर विचार करना चाहिए।

— स्ट्रगलर