Named Pipes व्यवहार में — design से security तक, Windows की standard IPC

“मैं चाहता हूँ कि एक resident service और settings UI commands आपस में बदलें।” “मैं केवल Administrator privilege चाहिए वाले काम को अलग process में अलग करना चाहता हूँ।” “मैं चाहता हूँ कि एक ही PC पर उपकरण एक-दूसरे को data दें।” — Windows पर जब इस तरह की inter-process communication (IPC) ज़रूरी हो जाती है, तो सबसे पहले विचार करने योग्य standard named pipe है।

Windows inter-process communication चुनने वाला लेख named pipes को “एक ही machine की IPC के लिए पहला उम्मीदवार” बताता है। यह लेख उसका विस्तृत उपचार है। वे पहला उम्मीदवार क्यों हैं, mode और server रूप कैसे चुनें, और privilege वाली service जब उन्हें use करे तो क्या सुरक्षित रखना चाहिए — Windows पर business apps और services लिखने वाले developers के लिए, ये design निर्णय primary sources से व्यवस्थित हैं।

1. निष्कर्ष पहले

• Named pipe \\.\pipe\name रूप के namespace वाला bidirectional inter-process channel है। एक ही नाम के नीचे कई instances बना सकते हैं और एक साथ कई clients स्वीकार कर सकते हैं।¹
• एक ही machine की IPC के लिए वे पहला उम्मीदवार इसलिए हैं कि security model मज़बूत है। ACL से कौन connect करे नियंत्रित कर सकते हैं, और server client के Windows account को देख और impersonate ले सकता है। Localhost TCP में इनमें से कुछ नहीं।²
• यदि “एक write = एक message” मानना हो तो message mode; यदि अपनी framing पहले से हो तो byte mode। Message mode में भी छोटे buffer पर split read (ERROR_MORE_DATA) सँभालनी पड़ती है।³
• कई clients “कई instances + overlapped I/O” या “.NET async/await” से सँभालें। Official sample एक thread पर कई instances process करने वाला रूप दिखाता है।⁴
• Security का न्यूनतम चार बिंदु है: remote reject (PIPE_REJECT_REMOTE_CLIENTS), ACL स्पष्ट करें, FILE_FLAG_FIRST_PIPE_INSTANCE से hijack पकड़ें, और client पक्ष पर impersonation level न्यूनतम रखें।⁵⁶
• ImpersonateNamedPipeClient के लिए return value जाँचना lifeline है। Failure ignore करें तो processing server के privileges पर चलती रहती है।⁶

2. Named Pipe क्या है — namespace, instance, और connection कैसे काम करते हैं

Named pipe \\.\pipe\MyCompany.MyApp.Control जैसे नाम से पहचाना जाने वाला channel है। Server इसे CreateNamedPipe से बनाता है, और client उसी नाम को CreateFile से खोलता है। खुलने के बाद दोनों पक्ष ReadFile / WriteFile से पढ़ते-लिखते हैं — typical बात यह है कि file I/O जैसा ही रूप use कर सकते हैं।¹

महत्वपूर्ण अवधारणा instance है। एक ही नाम की pipe के कई instances बना सकते हैं, और एक instance एक client के साथ एक channel है। पहली CreateNamedPipe call अधिकतम instance संख्या (या unlimited) तय करती है।³

Client-पक्ष connection का standard नुस्खा है। जब हर instance busy हो, CreateFile ERROR_PIPE_BUSY से fail होता है, इसलिए WaitNamedPipe से खाली का wait करें और फिर retry करें। साथ ही, खोलते समय specify पहुँच उस दिशा से मेल खानी चाहिए जो server ने बनाई — bidirectional pipe पढ़ने या लिखने किसी से भी खोली जा सकती है, पर outbound pipe जिसे server केवल लिखता है read-only के लिए खोलनी पड़ती है, और inbound pipe जिसे server केवल पढ़ता है write-only के लिए, वरना CreateFile fail होता है।⁷

flowchart TB
    accTitle: Pipe दिशा और client की पहुँच
    accDescr: Client bidirectional pipe को पढ़ने या लिखने किसी से खोल सकता है, पर server की write-only outbound pipe read-only, और read-only inbound pipe write-only के रूप में खोलनी चाहिए
    q{"Server ने बनाई दिशा?"} -->|"Bidirectional"| dc["पढ़ना या लिखना दोनों ठीक"]
    q -->|"Outbound"| oc["Read-only खोलें"]
    q -->|"Inbound"| ic["Write-only खोलें"]

चित्र 1: दिशा और access-specification का mismatch CreateFile failure बन जाता है। Connection error जाँचते समय पहले यहाँ देखें।

flowchart TB
    accTitle: Named pipe की बुनियादी structure
    accDescr: Server एक ही नाम के कई pipe instances बनाता है और ConnectNamedPipe से connection का wait करता है; हर client CreateFile से नाम खोलता है और एक instance के साथ one-to-one bidirectional channel पाता है
    s["Server"] --> i1["Instance 1"]
    s --> i2["Instance 2"]
    s --> i3["Instance 3"]
    c1["Client A"] <--> i1
    c2["Client B"] <--> i2
    c3["Client C"] <--> i3

चित्र 2: एक ही नाम के कई instances रखकर एक server एक साथ कई clients से one-to-one बात कर सकता है।

Named pipes SMB (\\server\pipe\name) से remote भी खोली जा सकती हैं, पर modern design में उसे सक्रिय use करने का लगभग कोई कारण नहीं; मुद्दा यह है कि जब use न कर रहे हों तो खुला न छोड़ें (अध्याय 5)।

3. Byte mode और message mode

Pipe के दो transfer modes हैं।³

• Byte mode (PIPE_TYPE_BYTE): TCP जैसा “अटूट byte stream”। एक message कहाँ खत्म होता है यह आप तय करते हैं (length-prefix जैसी framing design करते हैं)।
• Message mode (PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE): एक write एक message माना जाता है, और पाठक उसे उसी इकाई में पाता है। Request/response आदान-प्रदान के लिए यह आसान है।

Message mode का सुविधाजनक साथी TransactNamedPipe भी है, जो एक call में request भेजता और response पाता है।⁸ पर एक जाल है। यदि receive buffer पूरे message से छोटा हो, तो read ERROR_MORE_DATA लौटाती है और split read बन जाती है। यह न मानें कि message mode का अर्थ है “एक Read हमेशा पूरा ले आता है”; शेष पढ़ने वाला loop फिर भी लिखना पड़ता है। ध्यान दें कि read mode per-handle setting है, और CreateNamedPipe इसे केवल server पक्ष पर तय करता है। Client CreateFile के बाद SetNamedPipeHandleState से specify करता है (.NET में, connect के बाद ReadMode)।⁷

flowchart TB
    accTitle: Message mode में split-read loop
    accDescr: यदि ReadFile सफल हो तो message पूरा है; यदि ERROR_MORE_DATA आए तो buffer में न समाए शेष को पढ़कर जोड़ें; कोई अन्य error disconnect मानी जाती है
    read["ReadFile से पढ़ें"] --> r{"परिणाम?"}
    r -->|"सफलता"| done["Message पूरा"]
    r -->|"ERROR_MORE_DATA"| more["शेष पढ़ें और जोड़ें"]
    more --> read
    r -->|"कोई अन्य error"| dis["Disconnect मानें"]

चित्र 3: Message mode में भी “शेष-पढ़ने का loop” चाहिए; उसके बिना केवल बड़े messages टूटते हैं।

flowchart TB
    accTitle: Byte mode और message mode का अंतर
    accDescr: Byte mode में तीन writes अटूट byte stream बन जाते हैं और receiver को काटना पड़ता है; message mode में हर write की इकाई सुरक्षित रहती है और receiver तक वैसी ही पहुँचती है
    bw["Byte mode: AAA, BB, CCCC लिखें"] --> br["Stream AAABBCCCC के रूप में मिला"]
    br --> bf["Framing खुद design करें"]
    mw["Message mode: वही तीन writes"] --> mr["तीन messages: AAA, BB, CCCC"]
    mr --> mf["Write इकाइयाँ सुरक्षित"]

चित्र 4: Message mode “write की इकाई” सुरक्षित रखकर पहुँचाता है। Framing design अनावश्यक हो जाती है; केवल split read न भूलें।

चुनने का practical नियम सरल है। यदि आदान-प्रदान “request और response” रूप का हो, तो message mode। यदि ऐसा रूप ढो रहे हों जिसमें framing पहले से बनी हो (length-prefix serialized data या stream transfer), तो byte mode। .NET में PipeTransmissionMode.Message specify करना पहले वाले से मेल खाता है।⁹

4. Server design — per client एक thread, या Overlapped?

Server का बुनियादी operation loop है “instance बनाएँ → ConnectNamedPipe से client का wait → पढ़ें और लिखें → disconnect करें और अगले client पर जाएँ”। एक साथ कई clients से बात के दो रूप हैं।

Synchronous, per instance एक thread। हर instance को एक thread देते हैं, और प्रत्येक अपने client से synchronous I/O से बात करता है। Code सीधा है, पर per client एक thread खर्च होता है, और पूरा बंद करते समय blocking I/O से निकलने का तरीका भी चाहिए।

Overlapped (async)। Instance FILE_FLAG_OVERLAPPED से बनाते हैं, ConnectNamedPipe / ReadFile / WriteFile async जारी करते हैं, और थोड़े threads हर instance की completion सँभालते हैं। Microsoft का official sample WaitForMultipleObjects से event array पर wait करने वाला server दिखाता है जो एक thread पर कई instances process करता है।⁴ Async I/O का सामान्य विवरण I/O श्रृंखला लेख में है, और बड़े पैमाने पर IOCP या thread-pool I/O भी जोड़ सकते हैं।

flowchart TB
    accTitle: Overlapped server की structure
    accDescr: हर instance के async operation की completion event array पर आती है, और थोड़े threads WaitForMultipleObjects से wait कर पूर्ण instance आगे बढ़ाते हैं, जिससे thread संख्या client संख्या से अलग हो जाती है
    i1["Instance 1 async operation"] --> ev["Event array"]
    i2["Instance 2 async operation"] --> ev
    i3["Instance 3 async operation"] --> ev
    ev --> wait["WaitForMultipleObjects से wait"]
    wait --> proc["पूर्ण instance आगे बढ़ाएँ"]
    proc --> wait

चित्र 5: Overlapped रूप thread संख्या को client संख्या से अलग करता है। Official sample यह चक्र एक thread पर चलाता है।

.NET यह चुनाव लगभग हटा देता है। NamedPipeServerStream के WaitForConnectionAsync / ReadAsync / WriteAsync को async/await के साथ use करके, overlapped दक्षता synchronous रूप जितने सीधे code में मिलती है।⁹

// C#: कई क्लाइंट स्वीकार करने वाले सर्वर का कंकाल
while (!token.IsCancellationRequested)
{
    var server = new NamedPipeServerStream(
        "MyCompany.MyApp.Control",
        PipeDirection.InOut,
        NamedPipeServerStream.MaxAllowedServerInstances,
        PipeTransmissionMode.Message,
        PipeOptions.Asynchronous | PipeOptions.CurrentUserOnly);

    try
    {
        await server.WaitForConnectionAsync(token);
    }
    catch
    {
        await server.DisposeAsync();        // dispose yourself when leaving before a connection
        throw;
    }
    _ = HandleClientAsync(server, token);   // ownership after connect goes to the handler
}

PipeOptions.CurrentUserOnly यह specification है कि “केवल उसी user के process से connection अनुमति दें” — सुविधाजनक और सुरक्षित default जो ACL खुद लिखने से बचाता है।¹⁰ Users को पार करने वाले setup (service ↔ user session का app, आदि) में यह use नहीं हो सकता, इसलिए उस स्थिति में अगले अध्याय के ACL design पर जाएँ।

flowchart TB
    accTitle: .NET async server का accept loop
    accDescr: Accept loop NamedPipeServerStream बनाता है, WaitForConnectionAsync से connection का wait करता है, आने पर client handling async अलग कर तुरंत अगले accept पर लौटता है, इसलिए concurrent connections सीधे code में सँभलते हैं
    mk["Server stream बनाएँ"] --> wc["WaitForConnectionAsync से wait"]
    wc --> got["Connection आता है"]
    got --> hd["Client handling async अलग करें"]
    hd --> mk

चित्र 6: Accept loop “wait → अलग करें → अगला” चक्र पर टिका रहता है, और हर client की processing parallel चलती है।

5. Security — privilege वाली service जब pipe use करे तो चार अनिवार्य

Named pipes एक ही machine की IPC के लिए पहला उम्मीदवार इसलिए हैं कि security model है, पर वह केवल सही configure करने पर। खास कर broker design में “Administrator-privilege service + low-privilege UI app”, pipe खुद privilege boundary है। चार बिंदु पक्के करें।

(1) Remote reject करें। Local IPC के इरादे वाली pipe network से खुल सकना अपने आप attack-surface है। CreateNamedPipe पर PIPE_REJECT_REMOTE_CLIENTS specify करें तो remote-client connections स्वतः reject होते हैं।⁵

(2) ACL स्पष्ट करें। SECURITY_ATTRIBUTES में security descriptor दें और connect करने की अनुमति वाले users व groups संकीर्ण करें। Client को GENERIC_WRITE न दें — उसमें शामिल FILE_CREATE_PIPE_INSTANCE अधिकार authorized client को खुद उसी नाम का server instance बनाने और बाद के connections चुराने देगा। पढ़ना और लिखना अलग अधिकारों के रूप में दें, और instance-create अधिकार न दें।¹¹

(3) Name hijack रोकें। Pipe names first-come-first-served हैं। यदि malicious process उसी नाम की pipe पहले बनाए और wait करे, तो clients नकली server से जुड़ जाते हैं। Server पहला instance बनाते समय FILE_FLAG_FIRST_PIPE_INSTANCE specify करता है, जिससे “मैं पहले हूँ” की guarantee मिलती है, और यदि वह fail हो तो hijack संदेह कर रुक जाता है। यह flag केवल नाम दावे वाले पहले instance के लिए है; दूसरे और बाद के instances पर लगाने से create fail होता है।³

Server-पक्ष पहचान जाँच और privilege impersonate ImpersonateNamedPipeClient है। Pipe से request पढ़ने के बाद इसे call करें तो calling thread पढ़े गए अंतिम message के भेजने वाले के security context में चलने लगता है। Client के privileges से file खोलें तो access check client के against होती है — वह mechanism जिससे privilege वाली service “requested operation, requestor के privileges से” execute करती है।⁶ Use की पूर्ण शर्त return value जाँचना है। Impersonation fail होने के बाद आगे बढ़ें तो बाद के operations server के अपने ऊँचे privileges से चलते हैं। Official documentation स्पष्ट कहता है कि “failure पर client का request execute न करें”। काम के बाद RevertToSelf के साथ, impersonation token वाले लेख की प्रथाएँ ज्यों की त्यों लागू होती हैं।

sequenceDiagram
    accTitle: Impersonation use करने वाले request handling का flow
    accDescr: Server pipe से request पढ़ता है, ImpersonateNamedPipeClient की सफलता confirm करता है, फिर client के privileges से operation करता है और RevertToSelf से अपने context पर लौटता है। Impersonation fail हो तो request execute किए बिना reject करता है
    participant C as Client
    participant S as Server
    C->>S: Send a request
    S->>S: Read the request
    S->>S: ImpersonateNamedPipeClient
    Note over S: On failure, refuse without executing the request
    S->>S: Perform the operation with the client's privileges
    S->>S: RevertToSelf to restore the original context
    S->>C: Reply with the result

चित्र 7: Impersonation की सफलता की पुष्टि और विश्वसनीय RevertToSelf एक package हैं। Failure पर आगे बढ़ें तो server के privileges से चलता है।

flowchart TB
    accTitle: Privilege service की pipe बचाने वाले चार बिंदु
    accDescr: Server पक्ष remote reject, स्पष्ट ACL और first-instance guarantee से प्रवेश मज़बूत करता है; client पक्ष न्यूनतम impersonation level specify करता है ताकि नकली server privileges impersonate न ले सके（यदि design server को impersonate न देता हो तो identification level तक संकीर्ण करें）
    subgraph sv["Server पक्ष"]
        r1["PIPE_REJECT_REMOTE_CLIENTS"]
        r2["ACL से connector सीमित करें"]
        r3["FIRST_PIPE_INSTANCE（केवल पहला）"]
    end
    subgraph cl["Client पक्ष"]
        r4["न्यूनतम impersonation level"]
    end
    sv --> safe["Privilege boundary के रूप में pipe"]
    cl --> safe

चित्र 8: जिस design में pipe privilege boundary है, server-पक्ष के तीन बिंदु और client-पक्ष का एक बिंदु एक set के रूप में लागू करें।

6. व्यावहारिक जाल

Start-order race। यदि server ने pipe बनाने से पहले client connect आने लगे, तो “pipe मौजूद नहीं” error मिलती है। Client पक्ष में “मौजूद नहीं → थोड़ा रुककर retry” बनाएँ। इसके उल्टे, server पक्ष का सिद्धांत है client start होने से पहले ConnectNamedPipe से सुनना शुरू करना।⁸

flowchart TB
    accTitle: Client connection retry flow
    accDescr: CreateFile से pipe खोलें; यदि pipe मौजूद न हो तो थोड़ी wait कर retry करें; यदि हर instance busy हो（ERROR_PIPE_BUSY）तो WaitNamedPipe से खाली का wait कर retry करें; सफलता पर communication में प्रवेश करें
    cf["CreateFile से खोलें"] --> ok{"परिणाम?"}
    ok -->|"सफलता"| go["Communication शुरू करें"]
    ok -->|"Pipe मौजूद नहीं"| wait1["थोड़ी wait（server नहीं चला）"]
    ok -->|"ERROR_PIPE_BUSY"| wnp["WaitNamedPipe से खाली instance"]
    wait1 --> cf
    wnp --> cf

चित्र 9: Client connection handling “मौजूद नहीं” और “भरा” दो failures को अलग करती है और दोनों को retry में जोड़ती है।

Disconnect पकड़ना। साथी निकलने पर Read/Write ERROR_BROKEN_PIPE आदि से fail होते हैं। वह विसंगति नहीं; रोज़ का communication है। Server disconnect पकड़ता है, instance पर DisconnectNamedPipe करता है, और अगले connection की तैयारी करता है; client फिर जुड़ता है — sleep/resume वाले लेख में वर्णित “idempotent reconnect” का विचार यहाँ भी लागू होता है।

Message size की धारणाएँ। Message mode की split read (अध्याय 3) के ऊपर, यदि protocol के भाग के रूप में “एक message के अधिकतम bytes क्या हैं” न तय करें, तो malicious (या buggy) साथी विशाल message से memory बर्बाद कर सकता है। Upper bound तय करें, और पार होने पर disconnect करें; यही सुरक्षित तरीका है।

Write completion और साथी का प्राप्त करना अलग बातें हैं। WriteFile की सफलता का अर्थ यह नहीं कि साथी के app ने data process कर लिया। निश्चितता चाहिए वाले operations response message से पुष्टि, और protocol में request-response का मेल शामिल करने जैसे design से समर्थित होते हैं।

7. सारांश

• Named pipes एक ही machine की IPC के लिए पहला उम्मीदवार हैं। कारण file I/O जैसी सहजता, और ACL व impersonation के Windows security model से एकीकरण है।
• Mode चुनाव है “request और response के लिए message mode, अपनी framing पहले से हो तो byte mode”। Message mode में भी split read (ERROR_MORE_DATA) सँभालनी पड़ती है।
• कई clients कई instances + overlapped, या .NET async/await। नए काम के लिए .NET async रूप सीधा है।
• Privilege boundary वाली pipe पर remote reject, स्पष्ट ACL, FIRST_PIPE_INSTANCE (केवल पहला instance), और client-पक्ष impersonation level न्यूनतम — इन्हें एक set के रूप में लें।
• ImpersonateNamedPipeClient के लिए return value जाँचना और RevertToSelf lifeline हैं।
• “Communication का रोज़” — start order, disconnect, message upper bound, response पुष्टि — को protocol design में बुनें।

Named pipes पुरानी API हैं, पर “एक ही machine पर process को Windows account boundaries का सम्मान करते हुए बात करवाने” के use के लिए वे अभी भी सबसे स्वाभाविक उपकरण हैं। Design-निर्णय बिंदु लगभग इस लेख की सीमा में समाप्त हो जाते हैं। उसके बाद, implementation शुरू करने से पहले अपना protocol एक पन्ने पर लिख लें।

संबंधित लेख

• Windows inter-process communication का चुनाव ── Named Pipes / TCP / gRPC / Shared Memory / COM के लिए decision table
• Windows app में “केवल Administrator privilege चाहिए वाले काम” को ठोस रूप से अलग कैसे करें
• Windows Impersonation Token का सही use — thread पर privileges impersonate लेना और सुरक्षित वापसी
• Windows I/O की गहराई (भाग 2) — synchronous और async I/O: OVERLAPPED का वास्तविक अर्थ
• Shared memory की गलतियाँ और practical best practices

संबंधित परामर्श क्षेत्र

KomuraSoft LLC inter-process communication वाले design और implementation सँभालता है — service को UI app से अलग करना, Administrator privilege अलग करना, आदि — मौजूदा IPC (shared memory, घर का बना socket, COM, आदि) को named pipes से बदलना, और privilege वाली service की pipe communication की security review। Protocol design पर राय माँगने से परामर्श स्वागत योग्य है।

• Windows app development
• तकनीकी परामर्श और design review
• बग और कारणों की जाँच
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

Named pipes और TCP (localhost socket) में चुनाव कैसे करें?

एक ही machine पर inter-process communication के लिए named pipe पहला उम्मीदवार है। कारण security model है। Pipe Windows security descriptor (ACL) से OS स्तर पर नियंत्रित कर सकती है कि "कौन connect कर सकता है", और server ImpersonateNamedPipeClient से connect करने वाले साथी के Windows account को देख और impersonate ले सकता है। इसके उल्टे localhost TCP port से कोई भी connect कर सकता है, इसलिए साथी कौन है यह अपनी authentication से स्थापित करना पड़ता है। दूसरी ओर, जब बाद में remote communication बनने की संभावना हो, जब दूसरे OS के process से भी बात करनी हो, या जब gRPC जैसी मौजूदा protocol संपत्ति दोहरानी हो, तब TCP-based विकल्प लाभदायक हैं। यह निर्णय Windows inter-process communication चुनने वाले लेख में भी रखा गया है।

Byte mode use करें या message mode?

यदि आप "एक write = अर्थ की एक इकाई" मानना चाहते हैं, तो message mode (PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE) सुविधाजनक है। Receiver उसी इकाइयों में पढ़ सकता है जिनमें भेजने वाले ने लिखा, इसलिए boundaries खुद सँभालनी नहीं पड़तीं। Byte mode TCP जैसा "अटूट byte stream" है, और framing खुद design करनी पड़ती है — उदाहरण के लिए length-prefix। यदि आप ऐसा protocol ढो रहे हैं जिसमें framing पहले से है (जैसे length-prefix वाला serialized रूप), तो byte mode ठीक है। सावधानी: message mode में भी यदि receive buffer message से छोटा हो तो split read मिलती है (ERROR_MORE_DATA), इसलिए उसे भी सँभालना पड़ता है। साथ ही, read mode per-handle setting है, और CreateNamedPipe इसे केवल server पक्ष पर set करता है। Client को CreateFile के बाद SetNamedPipeHandleState से PIPE_READMODE_MESSAGE specify करना होता है। .NET में server PipeTransmissionMode.Message specify करता है, और client connect के बाद NamedPipeClientStream.ReadMode को Message set करता है।

एक साथ कई clients से बात करने वाला server कैसे बनाएँ?

Named pipe एक ही नाम के नीचे कई instances बना सकती है, और एक instance एक client सँभालता है। दो रूप हैं। एक synchronous design जो per client एक thread देता है; implementation सीधा है, पर per client एक thread खर्च होता है। दूसरा FILE_FLAG_OVERLAPPED से async I/O use करना और थोड़े threads से हर instance के ConnectNamedPipe, ReadFile और WriteFile सँभालना; Microsoft के official sample में एक thread पर कई instances process करने वाली implementation भी दिखती है। .NET में NamedPipeServerStream.WaitForConnectionAsync और async/await से async रूप लगभग उतनी ही सरलता से लिखा जा सकता है जितना synchronous। खास कारण न हो तो नई implementation के लिए .NET async रूप ही सुझाया जाता है।

Named-pipe security के लिए न्यूनतम क्या करना चाहिए?

चार बिंदु। पहला, यदि remote connection की ज़रूरत नहीं, तो PIPE_REJECT_REMOTE_CLIENTS specify करें और network से connection स्पष्ट रूप से reject करें। दूसरा, SECURITY_ATTRIBUTES से उपयुक्त ACL set करें और connect कर सकने वाले users व groups संकीर्ण करें (default ACL कुछ uses के लिए बहुत ढीला है)। तीसरा, पहला instance बनाते समय FILE_FLAG_FIRST_PIPE_INSTANCE specify करें, ताकि "name hijack" पकड़े जिसमें उसी नाम की pipe पहले बन जाए (दूसरे और बाद के instances पर यह flag न लगाएँ)। चौथा, जो client केवल server से अपनी पहचान करवाना चाहता है उसे CreateFile पर SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION specify करना चाहिए, ताकि नकली server उसके privileges impersonate न ले सके। Broker design में जहाँ server client के privileges के अधीन वास्तविक पहुँच करता है, impersonation की अनुमति देनी पड़ती है, इसलिए यह restriction design के अनुसार लगाएँ या न लगाएँ — इस पर depend कि server को privileges impersonate लेने दिए गए हैं या नहीं।

ImpersonateNamedPipeClient use करते समय क्या सावधानियाँ हैं?

सबसे महत्वपूर्ण return value जाँचना है। यदि impersonation fail होने के बाद भी आगे बढ़ें, तो बाद के operations server process के अपने (अक्सर ऊँचे) privileges से चलते हैं, और जो काम client को नहीं मिलने चाहिए थे वे pass हो जाते हैं। Official documentation स्पष्ट कहता है कि failure पर client का request execute न करें। इसे केवल कुछ पढ़ने के बाद ही call करें — impersonation "pipe से पढ़े गए अंतिम message" के context में होता है — और काम पूरा होने पर RevertToSelf से original context पर विश्वसनीय रूप से लौटें। Impersonation के आसपास की machinery (token, impersonation level, SeImpersonatePrivilege) impersonation token वाले लेख में विस्तार से है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।