Toolbox: घर का रास्ता समायोजित करें

मैं आमतौर पर कंटेनर बनाने से पहले केवल HOME=/home/user1/container1 करता हूं और उन्हें खोलने के लिए केवल उपनाम का उपयोग करता हूं। ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

हाँ, $HOME को ओवरराइड करना इसे करने का एक तरीका है।

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

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

• एक ~/.cargo निर्देशिका चुपचाप बनाई गई थी, जिसमें कुल 123 एमबी के लिए कई जंग से संबंधित बायनेरिज़, स्रोत पैकेज आदि शामिल थे।
• एक ~/.rustup निर्देशिका चुपचाप बनाई गई थी, जिसमें कुल 683 एमबी के लिए कई और जंग से संबंधित बायनेरिज़ शामिल थे।
• मेरी ~/.bash_profile फ़ाइल को अन्य सभी चीज़ों से पहले मेरे $PATH में ~/.cargo/bin निर्देशिका जोड़ने के लिए चुपचाप बदल दिया गया था।
• मेरी ~/.profile फ़ाइल को अन्य सभी चीज़ों से पहले मेरे $PATH में ~/.cargo/bin निर्देशिका जोड़ने के लिए चुपचाप बदल दिया गया था।
• और कौन जानता है।

ओह। एक अस्थायी, फालतू, आसानी से छोड़े जाने वाले सिस्टम के परिणामस्वरूप मेरे होम डायरेक्टरी में कई स्थायी परिवर्तन चुपचाप किए जा रहे थे। मुझे अब ऊपर की टिप्पणियों से पता चलता है कि मैं इसके आसपास काम करने की कोशिश करने के लिए मैन्युअल रूप से $ HOME पर्यावरण चर को ओवरराइड कर सकता हूं, लेकिन यह सहज या मेरे लिए अपेक्षित नहीं था। चूंकि टूलबॉक्स (या कम से कम जैसा कि मैं इसे समझता हूं) कंटेनरों में जाने का एक सरल और उपयोगकर्ता के अनुकूल तरीका माना जाता है, मैं सराहना करता हूं कि इसे कुछ बेहतर तरीके से संभाला जा सकता है।

मेरी राय यह है कि टूलबॉक्स में डिफ़ॉल्ट रूप से अपनी विशिष्ट उपयोगकर्ता और होम निर्देशिका होनी चाहिए। लेकिन अगर यह लागू करने के लिए बहुत जटिल है, तो शायद एक नया टूलबॉक्स बनाते समय कम से कम -h या --home तर्क हो सकता है, इसके डिफ़ॉल्ट $HOME को सेट करने के लिए? ताकि जब आप भविष्य में टूलबॉक्स में प्रवेश करें, तो यह $HOME मान अपने आप सेट हो जाएगा। उदाहरण के लिए, toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject की तर्ज पर कुछ।

मूल रूप से, मुझे लगता है कि यह बहुत अच्छा होगा यदि टूलबॉक्स के पास तीन मोड में से एक में कंटेनर स्थापित करने का उपयोगकर्ता के अनुकूल तरीका हो:

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

यह मुझे बहुत उचित लगता है। आपको क्या लगता है @debarshiray ??

मैं इस @JaneSmith का समर्थन करता हूं, मुझे बस इतना ही चाहिए - अच्छी तरह से!

मैं भी दूसरा विचार। लेकिन जब तक यह लागू नहीं हो जाता तब तक आप direnv का उपयोग कर सकते हैं। यह एक आसान उपकरण है जो प्रति निर्देशिका के आधार पर पर्यावरण चर निर्दिष्ट करने की अनुमति देता है। आप निम्न कार्य प्रवाह का उपयोग कर सकते हैं

- install direnv and hook it to your shell
- create a temporary directory eg. ~/somedev
- add a .envrc file with the environment variables you want (in this case HOME=/home/user/somedev

अब हर बार जब आप somedev निर्देशिका में जाते हैं तो यह मान लेगा कि यह होम निर्देशिका है और जब आप इससे बाहर निकलते हैं तो रीसेट हो जाता है। आप direnv को एक कमांड में स्थापित करने के बाद सभी चरणों को कर सकते हैं जैसे:

``` बैश
mkdir ~/somedev && इको एक्सपोर्ट HOME=/home/user/somedev > ~/somedev/.envrc
````
मैं वर्तमान में एक समान कार्य प्रवाह का उपयोग करता हूं।

मैं सहमत हूं कि कम से कम होम डीआईआर को माउंट न करने का विकल्प होना चाहिए (संदर्भ https://github.com/containers/toolbox/issues/183#issuecomment-623103780)। वास्तव में, अगर मैं फ्लैटपैक के समान - ~/.var/app में कुछ डीआईआर का उपयोग करता हूं, तो मैं भी ठीक रहूंगा, शायद बेहतर ~/.var/toolbox या तो, जहां होम डीआईआर में सभी फाइलें डिफ़ॉल्ट रूप से सहेजी जाती हैं।
मुझे वह फ्लैटपैक मॉडल काफी पसंद है, क्योंकि आपके पास एक कंटेनर से सभी डेटा एक ही स्थान पर है, और यदि आप कंटेनर को हटाते हैं, तो आप सभी ऐप डेटा को भी हटा सकते हैं। (या बस उस स्थान को मापें जो आपका नया "मैंने जंग की कोशिश की है" परियोजना ली है), उदाहरण के लिए (जैसा कि यह gnome-control-center में किया गया है)

फिर, सुविधा के लिए, यह संभवतः हमेशा वर्तमान $PWD में माउंट होना चाहिए, यदि आप इसे किसी प्रोजेक्ट फ़ोल्डर से शुरू करते हैं, तो संभवतः आपको वहां फ़ाइलें होने की उम्मीद है। बस, आपके ~/rust-project फ़ोल्डर को ~/Pictures/private/… आदि तक किसी एक्सेस की आवश्यकता नहीं है।

वैसे भी, निश्चित रूप से घर को केवल-पढ़ने के लिए या यहां तक ​​​​कि लिखने योग्य के रूप में वैकल्पिक रूप से माउंट करने में सक्षम होना चाहिए, लेकिन मुझे नहीं लगता कि अधिकांश अनुप्रयोगों के लिए वास्तव में इसकी आवश्यकता है।
और किसी को वर्तमान $PWD को माउंट नहीं करने में सक्षम होना चाहिए।

तो आपके पास एक नया डिफ़ॉल्ट के रूप में यहां "मध्य-मैदान" होगा।

tlbx fork में होम डाइरेक्टरी को बाइंड-माउंट न करने के लिए -n विकल्प है।

https://github.com/containers/toolbox/issues/183 . का डुप्लिकेट

नूओ ... आपके पास अभी भी एक अलग $ HOME होने के लिए अन्य उपयोग के मामले/कारण हो सकते हैं, फिर "विकास के तहत कोड में बग और मैलवेयर के खिलाफ अलग विकास वातावरण" ...

आईएमएचओ, यह अभी भी एक ऐसी सुविधा है जो टूलबॉक्स में होनी चाहिए।

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

@ जेनस्मिथ एक कांटा का उपयोग क्यों न करें यदि इसमें आपके लिए आवश्यक सुविधाएं हैं?

मैं कांटे के बजाय टूलबॉक्स का उपयोग करना पसंद करूंगा, क्योंकि टूलबॉक्स अधिक डेवलपर्स के साथ बेहतर समर्थित है, और फेडोरा के साथ बॉक्स से बाहर शामिल है। जब मैं मशीन से मशीन पर जा रहा होता हूं, तो टूलबॉक्स पहले से ही होता है, मेरे बिना कांटे स्थापित किए। टूलबॉक्स का पहली बार उपयोग करने का एक कारण यह है कि मेरे सिस्टम को यादृच्छिक सॉफ़्टवेयर इंस्टॉलेशन के साथ अव्यवस्थित होने से बचाना है!

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

@ जेनस्मिथ मैं सभी बिंदुओं पर सहमत हूं। मुझे उम्मीद है कि यह सुविधा पहली बार लागू की जाएगी जब वर्तमान असुरक्षित डिज़ाइन को सुरक्षा उल्लंघन में एक भूमिका निभाने के लिए प्रचारित किया जाता है, यदि जल्दी नहीं।

डॉक्स में पहला वाक्य कहता है कि यह _पूरी तरह से अनपेक्षित _ चलता है। सुरक्षित लगता है, हुह?

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

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

वर्तमान स्थिति न केवल असुरक्षित है, बल्कि यह बताने के लिए गुमराह करती है कि इस तरह के कंटेनरों का उपयोग महत्वपूर्ण सुरक्षा प्रदान करता है, जब ऐसा बहुत कम होता है कि कंटेनर आपकी सभी फाइलों तक पहुंच सकते हैं!

यदि आप रीडमे में "होम" की खोज करते हैं, तो ऐसा कोई दस्तावेज नहीं है कि आपकी होम निर्देशिका इस तरह से साझा की गई है।

मैं यह भी चाहता हूँ। एक बीच का मैदान (घर तक पहुंच योग्य, लेकिन घर के रूप में परिभाषित नहीं), और एक अधिक अविश्वसनीय मोड (घर बिल्कुल भी पहुंच योग्य नहीं है)।

मैं आमतौर पर कंटेनर बनाने से पहले केवल HOME=/home/user1/container1 करता हूं और उन्हें खोलने के लिए केवल उपनाम का उपयोग करता हूं। ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

यदि एक मध्यम जमीनी समाधान इतना आसान है... तो इसे टूलबॉक्स में एक विकल्प के रूप में क्यों नहीं लागू किया जा सकता है? टूलबॉक्स बनाते समय होम पाथ को एक तर्क के रूप में लें और इसे कहीं सेव करें, शायद उसी तरह जैसे कंटेनर का नाम कैसे सेव किया जाता है। फिर उस पथ को पढ़ें और कंटेनर में प्रवेश करते समय इसे सेट करें...

चीजों को थोड़ा और ठोस बनाने के लिए:

• --new-home जो टूलबॉक्स को होस्ट $HOME माउंट नहीं करने के लिए कहेगा (या इसे कंटेनर में कहीं और माउंट करें जो $HOME नहीं है)
• --from-home path1:path2:pathN जो टूलबॉक्स को होस्ट $HOME से कंटेनर होम तक विशिष्ट पथ माउंट करने के लिए कहेगा

तो उदाहरण के लिए यदि मेरे पास ~/प्रोजेक्ट्स में स्रोत निर्देशिकाएं हैं, तो जीपीजी के साथ चीजों पर हस्ताक्षर करने की आवश्यकता है और सर्वर से कनेक्ट करने के लिए एसएसएच की आवश्यकता है और मेरी गिट कॉन्फ़िगरेशन मैं इस तरह एक टूलबॉक्स बना सकता हूं:

toolbox create --new-home --from-home Projects:.ssh:.gnupg:.gitconfig

तो क्या यह कुछ अपस्ट्रीम स्वीकार किया जाएगा? अगर योजना समझ में आती है तो मैं इस पर भी काम करूंगा।