क्या / a / proc / फ़ाइल को पार्स करना सुरक्षित है?

Question

मैं पार्स करना चाहता हूं /proc/net/tcp/, लेकिन क्या यह सुरक्षित है?

मुझे फ़ाइलों को कैसे खोलना और पढ़ना चाहिए और कैसे /proc/डरना चाहिए, कि कुछ अन्य प्रक्रिया (या ओएस खुद) इसे उसी समय में बदल रही होगी?

Comments

+1। यह एक है लानत अच्छा प्रश्न है। मैं केवल यही चाहता हूं कि मेरे पास इसका उत्तर हो, लेकिन मैं यह जानने के लिए उत्सुक हूं कि मैंने उस तरह का काम पहले ही किया है।

— paxdiablo

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

— टिम पोस्ट

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

— रोरी अलसॉप

यही कारण है कि आपको इसके बजाय sysctl का उपयोग करना चाहिए। (इसके भी कम syscalls)

— अच्छा व्यक्ति

@GoodPerson - उदाहरण के लिए, यह sysctlमुझे /proc/net/tcp/फ़ाइल पार्स करने में कैसे मदद कर सकता है ?

— किरिल किरोव

Answer 1

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

उदाहरण के लिए:

• /proc/uptimeहै पूरी तरह से परमाणु , के रूप में किसी को एक और जवाब में बताया गया है - लेकिन केवल लिनक्स 2.6.30 के बाद से है, जो कम से कम दो साल पुराना है। तो यह छोटी, तुच्छ फ़ाइल तब तक एक दौड़ की स्थिति के अधीन थी, और अभी भी अधिकांश उद्यम गुठली में है। fs/proc/uptime.cवर्तमान स्रोत के लिए देखें , या प्रतिबद्ध है जिसने इसे परमाणु बना दिया । 2.6.30 पूर्व कर्नेल पर, आप openफ़ाइल कर सकते हैं , इसका readएक सा, फिर यदि आप बाद में readफिर से आते हैं, तो आपको जो टुकड़ा मिलेगा वह पहले टुकड़े के साथ असंगत होगा। (मैंने अभी यह प्रदर्शित किया है - इसे खुद मज़े के लिए आज़माएँ।)

• /proc/mountsहै एक भी भीतर परमाणु readसिस्टम कॉल। इसलिए यदि आप readपूरी फाइल एक ही बार में भरते हैं, तो आपको सिस्टम पर माउंट पॉइंट्स का एक एकल सुसंगत स्नैपशॉट मिलता है। हालाँकि, यदि आप कई readसिस्टम कॉल का उपयोग करते हैं - और यदि फ़ाइल बड़ी है, तो यह ठीक वैसा ही होगा यदि आप सामान्य I / O लाइब्रेरी का उपयोग करते हैं और इस मुद्दे पर विशेष ध्यान नहीं देते हैं - आप एक दौड़ के अधीन होंगे स्थिति। न केवल आपको एक सुसंगत स्नैपशॉट नहीं मिलेगा, बल्कि माउंट पॉइंट्स जो आपके शुरू होने से पहले मौजूद थे और कभी भी मौजूद नहीं होने से आप जो देखते हैं उसमें गायब हो सकते हैं। कि यह एक के लिए परमाणु से यह देखें read(), पर नज़र m_start()मेंfs/namespace.c है और यह एक सेमाफोर हड़पने देखते हैं कि गार्ड mountpoints की सूची है, जो यह जब तक रहता है m_stop(), जो कहा जाता है जबread()पूरा हो गया है। यह देखने के लिए कि क्या गलत हो सकता है, इस बग को पिछले साल से देखें (वही जो मैंने ऊपर लिंक किया है) अन्यथा उच्च गुणवत्ता वाले सॉफ़्टवेयर में जो ब्लिटली पढ़ता है /proc/mounts।

• /proc/net/tcp, जो कि आप वास्तव में पूछ रहे हैं, वह उससे भी कम सुसंगत है। यह केवल तालिका की प्रत्येक पंक्ति के भीतर परमाणु है । इसे देखने के लिए, एक ही फ़ाइल listening_get_next()मेंnet/ipv4/tcp_ipv4.c और established_get_next()नीचे देखें, और बदले में प्रत्येक प्रविष्टि पर वे ताले देखें। मेरे पास पंक्ति से पंक्ति में निरंतरता की कमी को प्रदर्शित करने के लिए रिप्रो कोड काम नहीं है, लेकिन वहां कोई भी लॉक नहीं है (या कुछ और) जो इसे सुसंगत बनाएगा। जो समझ में आता है अगर आप इसके बारे में सोचते हैं - नेटवर्किंग अक्सर सिस्टम का एक अति व्यस्त हिस्सा है, इसलिए इस नैदानिक ​​उपकरण में एक सुसंगत दृश्य प्रस्तुत करने के लिए ओवरहेड के लायक नहीं है।

अन्य टुकड़ा है कि रहता है /proc/net/tcpप्रत्येक पंक्ति के भीतर परमाणु में बफरिंग है seq_read(), जो आप पढ़ सकते हैं मेंfs/seq_file.c । यह सुनिश्चित करता है कि एक बार आप read()एक पंक्ति का हिस्सा होने के बाद, पूरी पंक्ति के पाठ को एक बफर में रखा जाता है ताकि read()नया शुरू करने से पहले अगले को उस पंक्ति के बाकी हिस्से मिल जाएं। एक ही तंत्र का उपयोग /proc/mountsप्रत्येक पंक्ति को परमाणु रखने के लिए किया जाता है, भले ही आप एकाधिक read()कॉल करते हों, और यह वह तंत्र भी है जिसका /proc/uptimeउपयोग नई गुठली में परमाणु रहने के लिए किया जाता है। वह तंत्र पूरी फ़ाइल को बफर नहीं करता है , क्योंकि कर्नेल मेमोरी के उपयोग के बारे में सतर्क है।

अधिकांश फाइलें /procकम से कम उतनी ही संगत /proc/net/tcpहोंगी, जितनी कि प्रत्येक पंक्ति में जो भी जानकारी वे प्रदान कर रहे हैं उसमें एक प्रविष्टि की एक सुसंगत तस्वीर होगी, क्योंकि उनमें से अधिकांश एक ही seq_fileअमूर्त का उपयोग करते हैं । /proc/uptimeउदाहरण के रूप में , हालांकि, कुछ फाइलें अभी भी seq_fileहाल ही में 2009 के रूप में उपयोग करने के लिए माइग्रेट की जा रही थीं ; मुझे यकीन है कि अभी भी कुछ ऐसे हैं जो पुराने तंत्र का उपयोग करते हैं और उनके पास परमाणु स्तर भी नहीं है। इन गुच्छों को शायद ही कभी दस्तावेज किया जाता है। किसी दिए गए फ़ाइल के लिए, आपकी एकमात्र गारंटी स्रोत को पढ़ना है।

के मामले में /proc/net/tcp, आप इसे पढ़ सकते हैं और बिना किसी डर के प्रत्येक पंक्ति को पार्स कर सकते हैं। लेकिन अगर आप एक साथ कई लाइनों से कोई निष्कर्ष निकालने की कोशिश करते हैं - खबरदार, अन्य प्रक्रियाएं और कर्नेल इसे पढ़ते समय बदल रहे हैं , और आप शायद एक बग बना रहे हैं।

Comments

रेडीमेड परमाणु के बारे में क्या? पढ़ना पसंद है / proc / self / fd? क्या ये सुरक्षित है?

— सॉकेटपेयर

ऐसा नहीं है कि यह सवाल का जवाब लेकिन कैसे अपटाइम की जांच करने के लिए आप उपयोग कर सकते हैं के बारे में जोड़ने के लिए clock_gettime(2)साथ CLOCK_MONOTONIC(हालांकि शायद एक तकनीकी मैं यहाँ से अनभिज्ञ हूं लेकिन मैं व्यक्तिगत रूप से केवल बूट के बाद से समय के साथ यह देखा है)। लिनक्स के लिए आपके पास भी विकल्प है sysinfo(2)।

— प्रातः

Answer 2

हालांकि में फ़ाइलों /procयूज़रस्पेस में नियमित रूप से फ़ाइलों के रूप में दिखाई देते हैं, वे वास्तव में फ़ाइलों बल्कि ऐसी इकाइयां हैं यूज़रस्पेस से मानक फ़ाइल आपरेशनों का समर्थन नहीं कर रहे हैं ( open, read, close)। ध्यान दें कि यह डिस्क पर एक साधारण फ़ाइल होने से काफी अलग है जिसे कर्नेल द्वारा बदला जा रहा है।

सभी कर्नेल करता है, अपनी आंतरिक स्थिति को एक समान sprintfफ़ंक्शन का उपयोग करके अपनी स्वयं की मेमोरी में प्रिंट करता है , और जब भी आप read(2)सिस्टम कॉल जारी करते हैं, तो उस मेमोरी को यूजरस्पेस में कॉपी किया जाता है ।

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

मेरी सलाह है कि अपने विशेष यूनिक्स स्वाद में एक खरीद फ़ाइल के कार्यान्वयन पर एक नज़र डालें। यह वास्तव में एक कार्यान्वयन मुद्दा है (जैसा कि प्रारूप और आउटपुट की सामग्री है) जो एक मानक द्वारा शासित नहीं है।

सबसे सरल उदाहरण uptimeलिनक्स में खरीद फ़ाइल का कार्यान्वयन होगा । ध्यान दें कि कॉलबैक फ़ंक्शन में पूरे बफर का उत्पादन कैसे किया जाता है single_open।

Comments

@ इग्नासियो: मैं सिर्फ इस दिशा में ओपी को इंगित कर रहा हूं क्योंकि मुझे इस धारणा के साथ छोड़ दिया गया था कि वह सोचता है कि procफाइलें कर्नेल द्वारा लिखने के लिए खोली गई साधारण फाइलें हैं।

— ब्लागोवेस्ट ब्युटुकलाइव

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

— ग्रेग की कीमत

Answer 3

/ proc एक वर्चुअल फाइल सिस्टम है: वास्तव में, यह सिर्फ कर्नेल इंटर्ल्स का एक सुविधाजनक दृश्य देता है। इसे पढ़ना निश्चित रूप से सुरक्षित है (इसीलिए यह यहाँ है) लेकिन यह दीर्घकालिक पर जोखिम भरा है, क्योंकि इन आभासी फ़ाइलों का आंतरिक कर्नेल के नए संस्करण के साथ विकसित हो सकता है।

संपादित करें

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

EDIT2

Sco doc के अनुसार (linux नहीं, लेकिन मुझे पूरा यकीन है कि सभी flix * nix उस तरह का व्यवहार करते हैं)

हालाँकि, प्रक्रिया की स्थिति और फलस्वरूप / proc फ़ाइलों की सामग्री तत्काल से तुरंत बदल सकती है, / proc फ़ाइल का एक एकल रीड (2) राज्य के प्रतिनिधित्व का `` समझदार '' वापस करने के लिए गारंटी है, अर्थात्, रीड होगा प्रक्रिया की स्थिति का एक परमाणु स्नैपशॉट। रनिंग प्रक्रिया के लिए / खरीद फ़ाइल के लिए लागू की गई क्रमिक रीड्स पर ऐसी कोई गारंटी लागू नहीं होती है। इसके अलावा, एटमिसिटी विशेष रूप से किसी भी I / O के रूप में (पता-स्थान) फ़ाइल के लिए लागू होने की गारंटी नहीं है; किसी भी प्रक्रिया के पता स्थान की सामग्री समवर्ती रूप से उस प्रक्रिया या सिस्टम में किसी अन्य प्रक्रिया के LWP द्वारा संशोधित की जा सकती है।

Comments

"मुझे लगता है" ? निश्चित उत्तर देना अच्छा होगा :)

— static_rtti

कर्नेल में / proc के कार्यान्वयन को देखते हुए, यह linux के लिए भी सही है। यदि आप एक एकल रीड कॉल में एक procfs फ़ाइल पढ़ते हैं, तो यह सुसंगत है - निश्चित रूप से आपके द्वारा पढ़ी गई proc फ़ाइल को सही ढंग से kelelside लागू किया गया है।

— एरिक

मुझे नहीं लगता कि आप एससीओ की तुलना में सूचना के बदतर संभावित स्रोत के साथ आ सकते हैं, और इलाज करने की कोशिश कर रहे हैं procजैसे कि यह विभिन्न गुठली के बीच समान व्यवहार है (या यहां तक ​​कि यह मौजूद है - यह एक यूनिक्स प्रणाली में नहीं है ) आपको चोट की एक दुनिया मिल रही है।

— निकोलस नाइट

@ निकोलस: ठीक है, कर्नेल डॉक में कुछ निश्चित जवाब नहीं मिला, अगर आप इसे जानते हैं तो इसे इंगित करने के लिए स्वतंत्र महसूस करें।

— ब्रूस

दिलचस्प है कि एससीओ डॉक्स का कहना है कि। दुर्भाग्य से यह लिनक्स में हमेशा सच नहीं होता है, और विशेष रूप से यह सच नहीं है /proc/net/tcp, जो ओपी की मुख्य चिंता है। बल्कि, आउटपुट में प्रत्येक व्यक्तिगत पंक्ति परमाणु है। विवरण के लिए मेरा उत्तर देखें।

— ग्रेग की कीमत

Answer 4

लिनक्स कर्नेल में procfs एपीआई यह सुनिश्चित करने के लिए एक अंतरफलक प्रदान करता है कि लगातार डेटा को पढ़ता है। में टिप्पणियों को पढ़ें __proc_file_read। आइटम 1) बड़ी टिप्पणी ब्लॉक में इस इंटरफ़ेस की व्याख्या करता है।

यह कहा जा रहा है, यह निश्चित रूप से इस इंटरफ़ेस का उपयोग करने के लिए एक विशिष्ट खरीद फ़ाइल के कार्यान्वयन तक है, यह सुनिश्चित करने के लिए कि उसका लौटा डेटा संगत है। तो, आपके प्रश्न का उत्तर देने के लिए: नहीं, कर्नेल एक रीड के दौरान खरीद फाइलों की संगति की गारंटी नहीं देता है, लेकिन यह उन फ़ाइलों के कार्यान्वयन के लिए साधन प्रदान करता है जो स्थिरता प्रदान करते हैं।

Comments

दुर्भाग्य से, /procवास्तव में कई फाइलें स्थिरता प्रदान नहीं करती हैं। विवरण के लिए मेरा उत्तर देखें।

— ग्रेग प्राइस

इसके अलावा, के __proc_file_read()पक्ष में पदावनत किया जाता है seq_file। लंबी ब्लॉक टिप्पणी के ठीक ऊपर (लीनस द्वारा) बल्कि अतिरंजित लगने वाली टिप्पणी देखें।

— ग्रेग मूल्य

Answer 5

मेरे पास लिनक्स 2.6.27.8 के लिए स्रोत है क्योंकि मैं एक एम्बेडेड एआरएम लक्ष्य पर फिलहाल ड्राइवर विकास कर रहा हूं।

फ़ाइल ... linux-2.6.27.8-lpc32xx/net/ipv4/raw.cलाइन 934 में, उदाहरण के लिए शामिल है

    seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
            " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
            i, src, srcp, dest, destp, sp->sk_state,
            atomic_read(&sp->sk_wmem_alloc),
            atomic_read(&sp->sk_rmem_alloc),
            0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
            atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));

जो आउटपुट देता है

[wally@zenetfedora ~]$ cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 15160 1 f552de00 299
   1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 13237 1 f552ca00 299
...

समारोह में raw_sock_seq_show()जो के एक पदानुक्रम का हिस्सा है procfs कार्यों से निपटने के। जब तक एक पाठ जेनरेट नहीं किया जाता read()अनुरोध से बना है /proc/net/tcpफ़ाइल, के बाद से एक उचित तंत्र procfs पढ़ता है निश्चित रूप से बहुत कम जानकारी को अद्यतन करने की तुलना में आम हैं।

कुछ ड्राइवर (जैसे मेरा) एक के साथ proc_read फ़ंक्शन को लागू करते हैं sprintf()। कोर ड्राइवरों के कार्यान्वयन में अतिरिक्त जटिलता संभावित रूप से बहुत लंबे आउटपुट को संभालना है जो एक ही पढ़ने के दौरान मध्यवर्ती, कर्नेल-स्पेस बफर में फिट नहीं हो सकता है।

मैंने परीक्षण किया कि 64K रीड बफ़र का उपयोग करने वाले प्रोग्राम के साथ लेकिन यह डेटा वापस करने के लिए proc_read के लिए मेरे सिस्टम में 3072 बाइट्स के कर्नेल स्पेस बफर में परिणाम करता है। एडवांसिंग पॉइंटर्स वाली मल्टीपल कॉल्स की जरूरत होती है ताकि ज्यादा से ज्यादा टेक्स्ट वापस आए। मुझे नहीं पता कि एक से अधिक i / o की आवश्यकता होने पर लौटाए गए डेटा को सुसंगत बनाने का सही तरीका क्या है। निश्चित रूप से प्रत्येक प्रविष्टि /proc/net/tcpआत्मनिर्भर है। कुछ संभावनाएं हैं कि अलग-अलग समय पर लाइनें साइड-बाय-साइड स्नैपशॉट हैं।

Comments

वास्तव में क्षमा करें, मुझे यह नहीं मिला। तो, क्या आपका मतलब यह है कि अगर मैं उपयोग करता हूं ifstream, तो यह असुरक्षित होगा, लेकिन अगर मैं इसका उपयोग readकरता हूं तो यह सुरक्षित होगा? या ifstreamआंतरिक रूप से उपयोग करता है read? और आप क्या सुझाव देते हैं?

— किरिल कीरोव

@Kiril: भ्रम के लिए क्षमा करें। यह इस बात का स्पष्टीकरण है कि डेटा किस प्रकार /proc/net/tcpस्वरूपित किया गया है और यह पूरी तरह से स्वतंत्र है कि कोई भी इसे कैसे पढ़ता है।

— wallyk

हां! और आपका अनुमान सही है कि अलग-अलग लाइनें (इन /proc/net/tcp) एक ही स्नैपशॉट से नहीं आती हैं। कुछ स्पष्टीकरण के लिए मेरा जवाब देखें।

— ग्रेग प्राइस

Answer 6

अज्ञात बगों में से कुछ में, दौड़ की कोई भी स्थिति नहीं होती है /procजो दूषित डेटा या पुराने और नए डेटा के मिश्रण को पढ़ने की ओर ले जाती है। इस लिहाज से यह सुरक्षित है। हालाँकि, अभी भी दौड़ की स्थिति है कि आपके द्वारा पढ़ा गया अधिकांश डेटा /procसंभावित रूप से पुराना है जैसे ही यह उत्पन्न होता है, और यहां तक ​​कि जब तक आप इसे पढ़ने / प्रसंस्करण करने के लिए प्राप्त करते हैं तब तक मोर्सो। उदाहरण के लिए प्रक्रियाएं किसी भी समय मर सकती हैं और एक नई प्रक्रिया को एक ही काम सौंपा जा सकता है; एक ही प्रक्रिया आईडी जिसे आप कभी भी दौड़ की स्थिति के बिना उपयोग कर सकते हैं, वह है आपकी अपनी बाल प्रक्रियाएँ ’। वही नेटवर्क जानकारी (ओपन पोर्ट्स इत्यादि) के लिए जाता है और वास्तव में अधिकांश जानकारी इसमें है /proc। मैं किसी भी डेटा पर भरोसा करने के लिए इसे बुरा और खतरनाक अभ्यास मानूंगा/procअपनी प्रक्रिया के बारे में डेटा और संभावित रूप से इसके बच्चे की प्रक्रियाओं को छोड़कर, सटीक होना। बेशक यह अभी भी /procजानकारीपूर्ण / लॉगिंग / आदि के लिए उपयोगकर्ता / व्यवस्थापक से अन्य जानकारी प्रस्तुत करने के लिए उपयोगी हो सकता है । प्रयोजनों।

Comments

मैं अपनी प्रक्रिया के लिए कुछ जानकारी प्राप्त करने और उपयोग करने के लिए ऐसा कर रहा हूं (मेरे पीआईडी ​​के लिए, उपयोग करके )। इसलिए, यह सुरक्षित होना चाहिए। getpid()

— किरिल

हां, मैं इस पर पूरी तरह से सुरक्षित विचार करूंगा।

— R .. गिटहब स्टॉप हेल्पिंग ICE

मैं इस बात से सहमत नहीं हूं कि बाल प्रक्रियाएं किसी भी अन्य प्रक्रिया की तुलना में बेहतर व्यवहार किया जाएगा। जहां तक /procइंटरफेस का सवाल है, वे सभी में समान कमजोरियां और ताकत हैं। वैसे भी, ओपी उपकरण चालक से संबंधित जानकारी के बारे में पूछता है, प्रक्रियाओं के बारे में नहीं।

— वैलीक

यदि पीआईडी Nआपकी बाल प्रक्रिया है, तो आप यह सुनिश्चित कर सकते हैं कि पिड Nअभी भी उसी (संभवत: समाप्त) प्रक्रिया को संदर्भित करता है जब तक आप waitउस पर -फैमिली फ़ंक्शन को कॉल नहीं करते हैं। यह सुनिश्चित करता है कि दौड़ नहीं हैं।

— R .. गिटहब स्टॉप हेल्पिंग ICE

-1 की बाढ़ के साथ क्या है और कोई स्पष्टीकरण नहीं है?

— आर .. गिटहब स्टॉप हेल्पिंग आईसीई

Answer 7

जब आप / proc फ़ाइल से पढ़ते हैं, तो कर्नेल एक फ़ंक्शन को कॉल कर रहा है जो कि इस "फ़ाइल" के लिए "रीड" फ़ंक्शन होने के लिए पहले से पंजीकृत है। देखें __proc_file_readFS / proc / generic.c में कार्य करते हैं।

इसलिए, पठन के अनुरोध को पूरा करने के लिए कर्नेल कॉल फ़ंक्शन के रूप में पठन की सुरक्षा केवल सुरक्षित है। यदि वह फ़ंक्शन ठीक से उस सभी डेटा को लॉक कर देता है जिसे वह छूता है और एक बफर में आपके पास लौटता है, तो उस फ़ंक्शन का उपयोग करके पढ़ना पूरी तरह सुरक्षित है। चूँकि फाइलों को संतुष्ट करने के लिए इस्तेमाल की जाने वाली फाइलों जैसे / proc / net / tcp को थोड़ी देर के लिए इधर-उधर किया गया है और उनकी समीक्षा की गई है, वे उतनी ही सुरक्षित हैं जितनी आप पूछ सकते हैं। वास्तव में, कई सामान्य लिनक्स उपयोगिताओं की खरीद फाइलसिस्टम से पढ़ने और आउटपुट को एक अलग तरीके से प्रारूपित करने पर निर्भर करती है। (मेरे सिर के ऊपर से, मुझे लगता है कि 'ps' और 'netstat' ऐसा करते हैं)।

हमेशा की तरह, आपको इसके लिए मेरा शब्द नहीं लेना होगा; आप अपने डर को शांत करने के लिए स्रोत को देख सकते हैं। Proc_net_tcp.txt से निम्न प्रलेखन आपको बताता है कि "पढ़ने" के लिए / proc / net / tcp लाइव के लिए क्या कार्य करता है, इसलिए आप उस वास्तविक कोड को देख सकते हैं जो उस खरीद फ़ाइल से पढ़ने पर चलाए जाने वाले वास्तविक कोड को देखता है और अपने लिए सत्यापित करता है कि कोई नहीं है बंद खतरों।

यह दस्तावेज़ इंटरफ़ेस / proc / net / tcp और / proc / net / tcp6 का वर्णन करता है।
ध्यान दें कि ये इंटरफेस tcp_diag के पक्ष में चित्रित किए गए हैं। ये / proc इंटरफेस वर्तमान में सक्रिय टीसीपी कनेक्शन के बारे में जानकारी प्रदान करते हैं, और नेट / ipv4 / tcp_ipv4.c और tcp6_seq_show () नेट / ipv6 / tcp_ipv6.c में क्रमशः tcp4_seq_show () द्वारा कार्यान्वित किए जाते हैं।