2010-07-21 8 views
23

मुझे यह चेतावनी मिलती है कि tmpnam खतरनाक है, लेकिन मैं इसका उपयोग करना पसंद करूंगा, क्योंकि इसका उपयोग विंडोज़ और लिनक्स में भी किया जा सकता है। मैं सोच रहा था कि इसे खतरनाक क्यों माना जाएगा (मुझे लगता है कि यह वास्तव में ठीक से काम नहीं कर रहा है बल्कि दुरुपयोग की संभावना के कारण है)।tmpnam चेतावनी कह रही है कि यह खतरनाक है

+0

क्या आप कुछ संदर्भ जोड़ सकते हैं? यह दावा कर रहा है कि यह खतरनाक है? – nmichaels

+0

'tmpname' एक परिवर्तनीय नाम है, एक फ़ाइल नाम, एक स्रोत फ़ाइल नाम या कुछ और पूरी तरह से? हम सभी में मानसिक क्षमता नहीं है। – sbi

+6

@ एसबीआई: 'tmpnam' एक मानक सी पुस्तकालय समारोह है। –

उत्तर

25
tmpnam मैनपेज से

:

tmpnam() फ़ंक्शन एक अलग स्ट्रिंग हर बार यह कहा जाता है TMP_MAX गुना तक उत्पन्न करता है। यदि इसे TMP_MAX बार से अधिक कहा जाता है, तो व्यवहार कार्यान्वयन परिभाषित किया जाता है।

हालांकि tmpnam() उन अनुमानों को उत्पन्न करता है जो अनुमान लगाना मुश्किल है, फिर भी यह संभव है कि उस समय के बीच जब tmpnam() पथनाम लौटाता है, और जब प्रोग्राम इसे खोलता है, तो दूसरा प्रोग्राम उस पथनाम को खुले (2), या इसे प्रतीकात्मक लिंक के रूप में बनाएं। इससे सुरक्षा छेद हो सकता है। ऐसी संभावनाओं से बचने के लिए, पथनाम खोलने के लिए खुले (2) O_EXCL ध्वज का उपयोग करें। या बेहतर अभी तक, mkstemp (3) या tmpfile (3) का उपयोग करें।

Mktemp वास्तव में फ़ाइल बनाते हैं, इसलिए आपको आश्वासन दिया जाता है कि यह काम करता है, जबकि tmpnam एक नाम देता है, संभवतः पहले से मौजूद है।

+2

'mktemp' का उपयोग करना केवल विंडोज़ के लिए यूनिक्स है, आपको' tmpnam_s' और '_wtmpnam_s' की आवश्यकता है। इस प्रकार एक मंच-स्वतंत्र संस्करण इतना आसान नहीं है। – usr1234567

1

tmpnam (3) मैनपेज से:

हालांकि tmpnam() नाम जिसका अनुमान लगाना मुश्किल हो जाता है उत्पन्न करता है, फिर भी संभव है कि समय के बीच कि tmpnam() एक पथ नाम देता है, और समय आ गया है कि प्रोग्राम इसे खोलता है, एक और प्रोग्राम उस पथ को बना सकता है- नाम खुले (2) का उपयोग करके, या इसे प्रतीकात्मक लिंक के रूप में बनाएं। इससे सुरक्षा छेद हो सकता है। ऐसे possibili- संबंधों से बचने के लिए, पथनाम खोलने के लिए खुले (2) O_EXCL ध्वज का उपयोग करें। या बेहतर अभी तक, mkstemp (3) या tmpfile (3) का उपयोग करें।

1

यदि आप MSVC का संकलक चेतावनी के बारे में बोलते हैं:

These functions are deprecated because more secure versions are available; 
see tmpnam_s, _wtmpnam_s. 

(http://msdn.microsoft.com/de-de/library/hs3e7355(VS.80).aspx)

अन्यथा सिर्फ manpages इस समारोह की खामियों के बारे में क्या कहते हैं पढ़ें। यह आमतौर पर एक ही प्रक्रिया के बारे में एक दूसरी प्रक्रिया है जो आपकी प्रक्रिया के समान ही है।

3

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

0

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

+3

एक प्री-प्रोसेसर निरंतर L_tmpnam है जो कार्यान्वयन की अधिकतम लंबाई निर्दिष्ट करता है (या एकल-थ्रेडेड प्रोग्राम में, आप एक नल पॉइंटर का उपयोग कर सकते हैं जिसमें यह एक स्थिर बफर का उपयोग करेगा)। इस प्रकार यह एक समस्या आसानी से टाल जाती है। खतरनाक हिस्सा फ़ाइल नाम बनाने के बीच संभावित दौड़ की स्थिति से आता है, और बाद में फ़ाइल को स्वयं बनाते हैं। – janneb

+0

अधिकतर सुरक्षा छेद से बचने में आसान है। (आपका उत्तर आपके द्वारा वर्णित समस्या से बचने का एक आसान तरीका बताता है)। यदि आप नियमों का पालन नहीं करते हैं तो मैं जिस समस्या का वर्णन करता हूं वह * होने की संभावना है। (यह भी tmpnam_s() द्वारा तय की गई समस्या है, इसलिए यह स्पष्ट रूप से समस्या है जिसके बारे में वे सोच रहे थे) –

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