लिनक्स में एक प्रतीकात्मक लिंक के मालिक को क्यों बदलें?


12

लिनक्स में एक प्रतीकात्मक लिंक के मालिक या समूह के मालिक (सिमिलिंक) को बदलना संभव है। मैं सोच रहा था कि कोई ऐसा क्यों करना चाहेगा, क्योंकि इसके माध्यम से किसी फ़ाइल को एक्सेस करते समय सिम्पीनल की अनुमति का उपयोग नहीं किया जाता है।

मैं केवल एक उपयोग के मामले की कल्पना कर सकता हूं, जहां यह उपयोगी हो सकता है: एक उपयोगकर्ता को चिपचिपा बिट के साथ एक निर्देशिका में एक सिमलिंक को हटाने की अनुमति देने के लिए।

क्या आप अन्य मामलों को जानते हैं जहां यह एक सिमलिंक के मालिक या समूह के मालिक को बदलने के लिए उपयोगी हो सकता है?

जवाबों:


6

मान लीजिए कि रूट एक निर्देशिका में काम कर रहा है जो ईव को लिख सकता है। fooइस निर्देशिका में एक फ़ाइल है जिसे ईव से संबंधित होने के लिए बदलना होगा। तो जड़ प्रकार chown eve foo। लेकिन रूट हिट होने से ठीक पहले एंटर, ईव रन करता है ln -sf /etc/passwd foo। अब /etc/passwdईव का है! यदि रूट chown -h eve fooयह सुनिश्चित करने के लिए चला सकता है कि सीमलिंक का पालन न करें, तो सबसे अधिक नुकसान यह हो सकता है कि ईव से संबंधित उसी निर्देशिका में कुछ अन्य फ़ाइल को बदल दिया गया है।

lchownजब आप किसी निर्देशिका ट्री के स्वामी को बदल रहे हों तो यह सुविधाजनक भी है। आपको गलती से पेड़ के बाहर किसी फ़ाइल को प्रभावित करने के बारे में चिंता करने की ज़रूरत नहीं है क्योंकि आपने chownएक प्रतीकात्मक लिंक पर कॉल किया है।


"अगर रूट chown -h bob foo चला सकता है, तो यह सुनिश्चित करने के लिए कि सिम्बलिंक का पालन न करें, तो सबसे अधिक नुकसान यह हो सकता है कि उसी निर्देशिका में कुछ अन्य फ़ाइल को ईव से संबंधित बदल दिया गया है।" मुझे लगता है कि आप का मतलब है "chown -h eve foo"। दूसरी फ़ाइल जिसे बदला जा सकता है, वह है प्रतीकात्मक लिंक क्या मैं सही हूं?
user368507

@ user5528 दूसरी फ़ाइल एक सिमलिंक नहीं हो सकती है: ईव अभी भी चल सकता है mv myfile foo, और रूट के मालिक को बदलना समाप्त हो जाएगा myfile। लेकिन myfileएक ऐसी फाइल होनी चाहिए जो ईव उस डायरेक्टरी में बना या ले जा सके, यह सिस्टम की कोई फाइल नहीं हो सकती है।
गिल्स एसओ- बुराई को रोकें '

2
हालांकि दिलचस्प, और स्पष्ट रूप से पूछने वाले द्वारा अनुमोदित है, मैं यह नहीं देखता कि यह उत्तर प्रश्न को कैसे संबोधित करता है। यह समझाने के लिए अधिक प्रतीत होता है chown -hकि किसी फ़ाइल को एक स्वामित्व के परिवर्तन के रूप में क्यों सावधानी से उपयोग किया जा सकता है, जिसे सिम्लिंक नहीं माना जाता है, लेकिन फिर भी (एक किनारा मामला, IMO) हो सकता है। यह स्पष्ट नहीं करता है कि कोई ऐसी फ़ाइल के स्वामित्व को बदलना क्यों चाहेगा जो वास्तव में एक सिमलिंक होने का इरादा रखता है, जो कि प्रश्न पूछा गया है।
इवान एक्स

chown"पेड़ के बाहर एक फ़ाइल" के मालिक को क्यों बदलना होगा आप जो बदल रहे हैं वह निर्देशिका का मालिक है?
Melab

@Melab जब आप एक डायरेक्टरी ट्री के मालिक को बदल रहे होते हैं , यानी यूटिलिटी को एक करते हैं chown -R, जो (l)chownप्रत्येक डायरेक्टरी एंट्री पर सिस्टम कॉल को कॉल करता है। यदि निर्देशिका प्रविष्टि एक प्रतीकात्मक लिंक है, तो आपको उस पर chownसिस्टम कॉल नहीं करना चाहिए क्योंकि यह लिंक के लक्ष्य को प्रभावित करेगा जो पेड़ के बाहर स्थित हो सकता है।
गिल्स एसओ- बुराई को रोकना '

8

यदि लिंक का स्वामी गंतव्य के स्वामी से मेल खाता है, तो अपाचे को केवल सीमलिंक का अनुसरण करने के लिए कॉन्फ़िगर किया जा सकता है। यह उपयोगकर्ताओं को उन फ़ाइलों तक वेब पहुंच के लिंक बनाने से रोकने में मदद कर सकता है जो उनके पास नहीं हैं (उदाहरण के लिए / etc / passwd)।

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


1
ठीक है। मुझे पता है कि यह असंबंधित है लेकिन अपाचे में इस व्यवहार का क्या मतलब है? मेरा मतलब है कि यदि उपयोगकर्ता फ़ाइल को पढ़ने में सक्षम है, तो उसे वेब एक्सेस से क्यों परेशान किया जाए? thx
user368507

खैर, यह सिर्फ फ़ाइल पढ़ने वाले स्थानीय उपयोगकर्ता नहीं है; यदि अपाचे इसे पढ़ सकता है, तो संभवतः हर कोई इसे पढ़ सकता है। और अगर कुछ अपाचे भेद्यता के लिए एक सिमलिंक के निर्माण की अनुमति दी जाती है /etc/passwd, तो बदमाश ने किसी अन्य स्थानीय पहुंच के बिना उस फ़ाइल तक पहुंच पढ़ी हो सकती है - लेकिन अपाचे के स्वामित्व वाले सिमलिंक को ठग लिया जाएगा।
लार्स रोहरबैच

4

पहला उत्तर प्रश्न को स्वीकार नहीं करता है, और दूसरा केवल अपाचे पर लागू होता है।

सामान्य रूप से लिनक्स के लिए एक बात मैं सोच सकता हूं कि यह केवल एक साधारण उपयोगकर्ता के लिए एक प्रतीकात्मक कड़ी के लिए एक कड़ी बनाना संभव है यदि उपयोगकर्ता प्रतीकात्मक लिंक का मालिक है। कोई ऐसा लिंक क्यों बनाना चाहेगा, मुझे नहीं पता।

एक और बात यह है कि एक साधारण उपयोगकर्ता केवल एक फ़ाइल के समूह के स्वामित्व को बदल सकता है यदि उपयोगकर्ता फ़ाइल का मालिक है (और जिस समूह को फ़ाइल में जोड़ा जा रहा है उसका सदस्य भी है।) यह सवाल लाता है कि समूह का स्वामित्व क्या है। एक प्रतीकात्मक लिंक करता है किसी संगठन में, यह इंगित करने के लिए टैग के रूप में उपयोगी हो सकता है कि किस टीम को लिंक की आवश्यकता होगी।

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

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


0

मेरे पास एक प्रोग्राम है जो एक लॉग फ़ाइल में जोड़ता है। इन लॉग फ़ाइलों को हर महीने एक अलग नाम से बनाया जाता है। इसके बजाय सॉफ्टवेयर का सटीक फ़ाइल नाम पता है, मैं एक "जेनेरिक" फ़ाइल नाम (data.log) का उपयोग करता हूं जो कि एक प्रतीकात्मक लिंक है जो उस महीने की वर्तमान फ़ाइल को इंगित करता है। यह एक क्रॉन जॉब पर स्वचालित है।

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


0

यदि आप अपनी प्रारंभिक स्क्रीन पर एक फ़ाइल के लिए एक लिंक रखना चाहते हैं, तो प्रतीकात्मक लिंक में होना चाहिए

"/ घर / उपयोगकर्ता नाम / डेस्कटॉप"

निर्देशिका।

और, प्रतीकात्मक लिंक में स्वयं रूट होना चाहिए: रूट (0: 0) स्वामित्व, अन्यथा लिंक काम नहीं करता है।

(उबंटू / डेबियन आदि)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.