2011-03-10 10 views
13

हम एक गिट रेपो का उपयोग करते हैं जो किसी दूरस्थ स्थान पर होस्ट किया जाता है, और साझा किया जाता है। हम रिपो को उपयोगकर्ता & समूह पठनीय & लिखने योग्य चाहते हैं, लेकिन अन्य के लिए कोई अनुमति नहीं है। रिमोट रेपो का एक अलग उपयोगकर्ता (आरयूसर कहता है) का स्वामित्व है। मैंने अपने स्थानीय रेपो के साथ-साथ रिमोट रेपो में core.sharedRepository0660 सेट किया है। इसके अलावा, मेरा उमास्क 0027 है। इसलिए, जब भी मैं एक नई फाइल बनाता हूं, तो उसके पास अन्य के लिए कोई अनुमति नहीं है।गिट पुश सम्मान अनुमतियाँ बनाना?

इस सबके बावजूद, जब भी मैं रिमोट रेपो में बदलाव करता हूं, तो यह निर्देशिका में -r--r--r-- के साथ कुछ नई ऑब्जेक्ट बनाता है। यहां तक ​​कि वीडर भी है कि यह मुझे (दूरस्थ उपयोगकर्ता के बजाय) निर्देशिका/फ़ाइलों के मालिक बनाता है। कोई विचार क्या चल रहा है?

मैंने स्टैक ओवरफ्लो पर कई प्रतीत होता है संबंधित प्रश्नों पर जाकर एक जवाब खोजने का प्रयास किया, लेकिन कुछ भी नहीं मिला।

+0

आप रिमोट रिपोजिटरी का उपयोग कैसे कर रहे हैं? ऐसा लगता है कि आप एक एसएसएच-आधारित विधि ('होस्ट: पथ' या' ssh: // होस्ट/पथ 'भंडार URL का उपयोग कर रहे हैं)। यदि आप इसके बजाय नेटवर्क फाइल सिस्टम का उपयोग कर रहे हैं, तो यह जटिल चीजें हो सकती है। –

+0

मैं एसएसएच का उपयोग कर उपयोग कर रहा हूं, और रिमोट फाइल सिस्टम वास्तव में एक एनएफएस फाइल सिस्टम है (मुझे यकीन नहीं है कि फाइल सिस्टम यहां कुछ भी क्यों प्रभावित करेगा)। – user10

उत्तर

13

नोट: मुझे लगता है कि आप प्रत्येक उपयोगकर्ता को अपने उपयोगकर्ता के रूप में सर्वर में लॉग इन करने के साथ एक एसएसएच-आधारित एक्सेस तंत्र का उपयोग कर रहे हैं (यानी आपके पास एकाधिक उपयोगकर्ताओं को रिपॉजिटरी तक पहुंचने के लिए एक खाते में लॉगिन नहीं है)। यदि यह धारणा सत्य नहीं है, तो निम्न उत्तर पूरी तरह से उपयोगी नहीं हो सकता है।


अपने व्यक्तिगत भंडार की core.sharedrepository स्थापित करने और umask आप इसे उपयोग करने का उपयोग स्वामित्व और अनुमतियाँ एक दूरस्थ भंडार पर इस्तेमाल के लिए अप्रासंगिक हैं।

रिमोट रिपोजिटरी में core.sharedrepository से 0660 सेट करना आप जो चाहते हैं उसे प्राप्त करने का सही तरीका है। रिमोट साइड पर पहुंचने वाले उपयोगकर्ता के उमास्क भी अप्रासंगिक है क्योंकि गिट core.sharedrepository के लिए मान को देखते हुए मास्क ओवरराइड करेगा। आपको यह सुनिश्चित करने की ज़रूरत है कि सभी फाइलें और निर्देशिकाएं आपके सामान्य समूह द्वारा समूह-स्वामित्व वाली हैं और अनुमतियां सही हैं (2770 सभी निर्देशिकाओं के लिए (या बस 770 बीएसडी-आईएसएच सिस्टम के लिए); 440objects/?? और /objects/pack/ के तहत फ़ाइलों के लिए; अन्य फ़ाइलों के लिए 660)।

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

प्रत्येक उपयोगकर्ता स्पष्ट रूप से किसी भी फाइल निर्देशिका वे बनाने उपयोगकर्ता के स्वामी होगा /, लेकिन वे भी उपयोगकर्ता के स्वयं के सबसे फ़ाइलों वे संशोधित करेगा कि क्योंकि Git "परमाणु पुनर्लेखन" का उपयोग करता है (यह करने के लिए नई सामग्री लिखता है एक ही निर्देशिका में एक नई, अलग फ़ाइल, और उसके बाद इसे मूल फ़ाइल के ऊपर नामित करता है)।

शायद गिट नई फाइलों के लिए उमास्क को ओवरराइड करने के तरीके में एक बग है। वास्तव में कौन सी फाइलें अनुमतियां प्राप्त कर रही हैं जो बहुत व्यापक हैं? भंडार पर पहुंच के लिए रिमोट एंड पर गिट का कौन सा संस्करण है? आप रिमोट एंड पर क्या ओएस चल रहे हैं?

मैं इस समस्या को गिट 1.7.4.1 के साथ दो उपयोगकर्ताओं और मेरे यूनिक्स मशीन पर एक आम समूह के साथ पुन: उत्पन्न करने में असमर्थ था।

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

+0

आपके उत्तर क्रिस के लिए धन्यवाद। हालांकि, मेरे लिए एक बहुत ही साधारण काम काम किया। मैंने रेपो की अपनी व्यक्तिगत प्रति हटा दी, और एक ब्रांड नई प्रतिलिपि की जांच की। और अब चीजें काम करती हैं क्योंकि उन्हें सभी अनुमतियों का सम्मान करना चाहिए। मैं गिट के संस्करण 1.7.2.2 का उपयोग कर रहा हूँ। – user10

+1

संबंधित के बारे में एक नोट - साझा: यह उमास्क करता है जैसे आप काम नहीं कर रहे हैं, इसके बजाय आप अनुमतियों को निर्दिष्ट कर रहे हैं। --shared = 0077 इसलिए इसका मतलब है कि मालिक इसका उपयोग नहीं कर सकता है, लेकिन समूह और दुनिया कर सकते हैं। (यह इस विकल्प को अस्वीकार कर देगा) जबकि --shared = 0700 का मतलब है कि मालिक केवल इसका उपयोग कर सकता है। –

-2

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

संबंधित मुद्दे