Named pipe dalam praktik — IPC andalan Windows, dari desain sampai keamanan

Ingin bertukar perintah antara layanan yang selalu berjalan dan aplikasi UI pengaturan. Ingin memisahkan ke proses lain hanya pekerjaan yang membutuhkan hak administrator. Ingin saling mengirim data antar tool di PC yang sama. Ketika komunikasi antarproses (IPC) semacam ini diperlukan di Windows, standar yang patut ditimbang lebih dulu adalah named pipe.

Artikel tabel keputusan komunikasi antarproses menempatkan named pipe sebagai “kandidat pertama IPC di mesin yang sama”. Artikel ini adalah pembahasan rincinya. Mengapa kandidat pertama, bagaimana memilih mode dan konfigurasi server, dan apa yang harus dilindungi ketika layanan berhak istimewa memakainya. Untuk pengembang yang menulis aplikasi bisnis dan layanan di Windows, bahan keputusan desain disusun berdasarkan sumber primer.

1. Kesimpulan lebih dulu

• Named pipe adalah saluran komunikasi antarproses dua arah dengan ruang nama \\.\pipe\nama. Beberapa instance dapat dibuat dengan nama yang sama, sehingga beberapa klien dapat diterima sekaligus.¹
• Alasan menjadi kandidat pertama untuk IPC di mesin yang sama adalah model keamanannya. ACL dapat mengontrol siapa yang terhubung, dan server dapat memeriksa serta meminjam (meng-impersonate) akun Windows klien. TCP localhost tidak punya keduanya.²
• Jika ingin memperlakukan “satu penulisan = satu pesan”, pakai mode pesan; jika sudah punya framing sendiri, pakai mode byte. Bahkan dalam mode pesan, pembacaan terpecah saat buffer kurang (ERROR_MORE_DATA) tetap harus ditangani.³
• Beberapa klien ditangani dengan “beberapa instance + overlapped I/O” atau “.NET async/await”. Sampel resmi menunjukkan bentuk yang memproses beberapa instance di satu thread.⁴
• Garis minimum keamanan adalah empat poin: tolak jarak jauh (PIPE_REJECT_REMOTE_CLIENTS), ACL eksplisit, deteksi pembajakan lewat FILE_FLAG_FIRST_PIPE_INSTANCE, dan minimalkan tingkat impersonation di sisi klien.⁵⁶
• Untuk ImpersonateNamedPipeClient, memeriksa nilai kembalian adalah nyawa. Jika kegagalan diabaikan, pemrosesan berjalan dengan hak server.⁶

2. Apa itu named pipe — ruang nama, instance, dan bentuk koneksi

Named pipe adalah saluran yang dikenali dengan nama seperti \\.\pipe\MyCompany.MyApp.Control. Server membuatnya dengan CreateNamedPipe, dan klien membuka nama yang sama dengan CreateFile. Setelah terbuka, kedua sisi membaca dan menulis dengan ReadFile / WriteFile — ciri khasnya adalah dapat dipakai dalam bentuk yang sama seperti I/O berkas.¹

Konsep penting adalah instance. Pipe dengan nama yang sama dapat dibuat dalam beberapa instance, dan satu instance adalah satu saluran dengan satu klien. Panggilan CreateNamedPipe pertama menentukan jumlah instance maksimum (atau tanpa batas).³

Koneksi di sisi klien punya tata cara yang sudah umum. Ketika semua instance sedang dipakai, CreateFile gagal dengan ERROR_PIPE_BUSY, jadi tunggu yang kosong dengan WaitNamedPipe lalu coba lagi. Selain itu, akses yang ditentukan saat membuka harus cocok dengan arah yang dibuat server — pipe dua arah dapat dibuka dengan spesifikasi baca maupun tulis, tetapi outbound yang hanya ditulis server harus dibuka hanya-baca, dan inbound yang hanya dibaca server harus dibuka hanya-tulis, atau CreateFile gagal.⁷

flowchart TB
    accTitle: Arah pipe dan spesifikasi akses klien
    accDescr: Pipe dua arah dapat dibuka klien dengan spesifikasi baca maupun tulis, tetapi outbound yang hanya ditulis server harus dibuka hanya-baca, dan inbound yang hanya dibaca server harus dibuka hanya-tulis
    q{"Arah yang dibuat server?"} -->|"Dua arah"| dc["Baca maupun tulis boleh"]
    q -->|"Outbound"| oc["Buka hanya-baca"]
    q -->|"Inbound"| ic["Buka hanya-tulis"]

Gambar 1: Ketidakcocokan arah dan spesifikasi akses berujung pada kegagalan CreateFile. Saat menelusuri kesalahan koneksi, periksa ini lebih dulu.

flowchart TB
    accTitle: Struktur dasar named pipe
    accDescr: Server membuat beberapa instance pipe dengan nama yang sama dan menunggu koneksi dengan ConnectNamedPipe; setiap klien membuka nama itu dengan CreateFile dan memiliki saluran dua arah satu-ke-satu dengan satu instance
    s["Server"] --> i1["Instance 1"]
    s --> i2["Instance 2"]
    s --> i3["Instance 3"]
    c1["Klien A"] <--> i1
    c2["Klien B"] <--> i2
    c3["Klien C"] <--> i3

Gambar 2: Dengan beberapa instance bernama sama, satu server dapat berkomunikasi satu-ke-satu dengan beberapa klien sekaligus.

Named pipe juga dapat dibuka dari jarak jauh lewat SMB (\\server\pipe\nama), tetapi dalam desain modern hampir tidak ada alasan untuk memakainya secara aktif. Yang jadi isu justru jangan biarkan tetap terbuka jika tidak dipakai (Bab 5).

3. Mode byte dan mode pesan

Pipe punya dua mode transfer.³

• Mode byte (PIPE_TYPE_BYTE): “aliran byte tanpa potongan” seperti TCP. Di mana satu pesan berakhir harus ditentukan sendiri (merancang framing seperti prefix panjang).
• Mode pesan (PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE): satu penulisan diperlakukan sebagai satu pesan, dan sisi baca menerimanya dalam satuan itu. Untuk pertukaran permintaan-respons, ini lebih mudah.

Mode pesan punya pendamping yang berguna: TransactNamedPipe, yang mengirim permintaan dan menerima respons dalam satu kali panggilan.⁸ Ada juga jebakannya. Jika buffer terima lebih kecil dari seluruh pesan, pembacaan mengembalikan ERROR_MORE_DATA dan menjadi pembacaan terpecah. Jangan berasumsi bahwa mode pesan berarti “satu Read selalu membawa keseluruhan”; loop untuk membaca sisanya tetap perlu ditulis. Mode baca adalah pengaturan per handle; yang diputuskan CreateNamedPipe hanya sisi server. Klien menentukannya dengan SetNamedPipeHandleState setelah CreateFile (ReadMode setelah terhubung di .NET).⁷

flowchart TB
    accTitle: Loop pembacaan terpecah pada mode pesan
    accDescr: Jika ReadFile berhasil, pesan selesai; jika ERROR_MORE_DATA, sisa yang tidak muat di buffer dibaca lagi lalu digabung; error lain diperlakukan sebagai putus koneksi
    read["Baca dengan ReadFile"] --> r{"Hasilnya?"}
    r -->|"Berhasil"| done["Pesan selesai"]
    r -->|"ERROR_MORE_DATA"| more["Baca sisa lalu gabungkan"]
    more --> read
    r -->|"Error lain"| dis["Perlakukan sebagai putus koneksi"]

Gambar 3: Bahkan dalam mode pesan, loop “baca sisanya” tetap diperlukan. Tanpa itu, hanya pesan besar yang rusak.

flowchart TB
    accTitle: Perbedaan mode byte dan mode pesan
    accDescr: Pada mode byte, tiga penulisan menjadi aliran byte tanpa potongan dan penerima harus memotongnya sendiri; pada mode pesan, satuan tiap penulisan dipertahankan dan sampai ke penerima apa adanya
    bw["Mode byte: tulis AAA, BB, CCCC"] --> br["Yang diterima: aliran byte AAABBCCCC"]
    br --> bf["Batas (framing) dirancang sendiri"]
    mw["Mode pesan: tiga penulisan yang sama"] --> mr["Yang diterima: tiga pesan AAA, BB, CCCC"]
    mr --> mf["Satuan penulisan dipertahankan"]

Gambar 4: Mode pesan mempertahankan “satuan penulisan” sampai ke penerima. Framing tidak perlu dirancang, tetapi penanganan pembacaan terpecah jangan dilupakan.

Petunjuk praktis memilihnya sederhana. Jika pertukarannya berbentuk permintaan dan respons, pakai mode pesan. Jika yang dialirkan sudah format yang membawa framing (data serialisasi berpanjang atau transfer stream), pakai mode byte. Di .NET, menentukan PipeTransmissionMode.Message sesuai dengan yang pertama.⁹

4. Desain server — tipe thread sinkron atau tipe overlapped

Operasi dasar server adalah pengulangan “buat instance → tunggu klien dengan ConnectNamedPipe → baca/tulis → putuskan lalu ke klien berikutnya”. Ada dua bentuk untuk melayani beberapa klien sekaligus.

Tipe thread sinkron. Satu thread dialokasikan per instance, masing-masing melayani kliennya sendiri dengan I/O sinkron. Kodenya lugas, tetapi mengonsumsi thread sebanyak jumlah klien, dan saat berhenti secara keseluruhan (shutdown) perlu cara untuk keluar dari I/O yang memblokir.

Tipe overlapped (asinkron). Instance dibuat dengan FILE_FLAG_OVERLAPPED, lalu ConnectNamedPipe / ReadFile / WriteFile dikeluarkan secara asinkron, dan sejumlah kecil thread menangani penyelesaian semua instance. Sampel resmi Microsoft menunjukkan server yang menunggu array event dengan WaitForMultipleObjects dan memproses beberapa instance di satu thread.⁴ Pembahasan umum I/O asinkron sudah dijelaskan di artikel serial I/O; jika skalanya besar, koneksi ke IOCP atau I/O thread pool juga bisa dipilih.

flowchart TB
    accTitle: Struktur server tipe overlapped
    accDescr: Penyelesaian operasi asinkron tiap instance diterima lewat array event; sejumlah kecil thread menunggu dengan WaitForMultipleObjects lalu memajukan pemrosesan instance yang selesai, sehingga jumlah thread dipisahkan dari jumlah klien
    i1["Operasi asinkron instance 1"] --> ev["Array event"]
    i2["Operasi asinkron instance 2"] --> ev
    i3["Operasi asinkron instance 3"] --> ev
    ev --> wait["Tunggu penyelesaian dengan WaitForMultipleObjects"]
    wait --> proc["Majukan pemrosesan instance yang selesai"]
    proc --> wait

Gambar 5: Tipe overlapped memisahkan jumlah thread dari jumlah klien. Sampel resmi memutar siklus ini di satu thread.

Di .NET, pilihan ini hampir tidak perlu dirisaukan. Dengan WaitForConnectionAsync / ReadAsync / WriteAsync pada NamedPipeServerStream plus async/await, efisiensi tipe overlapped didapat dengan kode yang hampir sama lugasnya seperti tipe sinkron.⁹

// C#: kerangka server yang menerima beberapa klien
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();        // jika keluar sebelum terhubung, dispose sendiri
        throw;
    }
    _ = HandleClientAsync(server, token);   // setelah terhubung, kepemilikan pindah ke handler
}

PipeOptions.CurrentUserOnly berarti “hanya izinkan koneksi dari proses pengguna yang sama” — default yang mudah dan aman tanpa menulis ACL sendiri.¹⁰ Tidak dapat dipakai pada konfigurasi lintas pengguna (layanan ↔ aplikasi sesi pengguna, dan semacamnya); dalam kasus itu lanjut ke desain ACL di bab berikutnya.

flowchart TB
    accTitle: Loop penerimaan server asinkron .NET
    accDescr: Loop penerimaan membuat NamedPipeServerStream, menunggu koneksi dengan WaitForConnectionAsync, lalu melepaskan penanganan klien secara asinkron dan segera kembali menerima berikutnya, sehingga koneksi simultan ditangani dengan kode yang lugas
    mk["Buat stream server"] --> wc["Tunggu dengan WaitForConnectionAsync"]
    wc --> got["Koneksi tiba"]
    got --> hd["Lepaskan penanganan klien secara asinkron"]
    hd --> mk

Gambar 6: Loop penerimaan hanya berputar “tunggu → lepas → berikutnya”; penanganan tiap klien berjalan secara paralel.

5. Keamanan — empat poin wajib jika dipakai layanan berhak istimewa

Alasan terbesar named pipe menjadi kandidat pertama IPC di mesin yang sama adalah model keamanannya, tetapi itu jika dikonfigurasi dengan benar. Terutama pada konfigurasi broker “layanan berhak administrator + aplikasi UI berhak rendah”, pipe itu sendiri menjadi batas hak. Ada empat poin yang harus dipegang.

(1) Tolak jarak jauh. Pipe yang dimaksudkan sebagai IPC lokal tetapi dapat dibuka dari jaringan sudah merupakan permukaan serangan. Jika PIPE_REJECT_REMOTE_CLIENTS ditentukan pada CreateNamedPipe, koneksi klien jarak jauh ditolak secara otomatis.⁵

(2) Buat ACL eksplisit. Serahkan security descriptor lewat SECURITY_ATTRIBUTES dan persempit pengguna serta grup yang diizinkan terhubung. Jangan memberi GENERIC_WRITE kepada klien — hak FILE_CREATE_PIPE_INSTANCE yang terkandung di dalamnya memungkinkan klien yang diizinkan membuat instance server bernama sama dan merebut koneksi berikutnya. Berikan baca dan tulis sebagai hak terpisah, dan jangan menyerahkan hak membuat instance.¹¹

(3) Cegah pembajakan nama. Nama pipe adalah siapa cepat dia dapat. Jika proses jahat membuat pipe bernama sama lebih dulu dan menunggu, klien terhubung ke server palsu. Server menentukan FILE_FLAG_FIRST_PIPE_INSTANCE saat membuat instance pertama, menjamin “dirinyalah yang pertama”, dan jika gagal, curigai pembajakan lalu berhenti. Flag ini khusus untuk instance pertama yang mengamankan nama; jika dipasang pada yang kedua dan seterusnya, pembuatan gagal.³

Identifikasi dan peminjaman hak di sisi server adalah ImpersonateNamedPipeClient. Memanggilnya setelah membaca permintaan dari pipe membuat thread pemanggil mulai bergerak dalam konteks keamanan pengirim pesan yang terakhir dibaca. Jika berkas dibuka dengan hak klien, keputusan akses mengikuti klien — mekanisme agar layanan berhak istimewa menjalankan “operasi yang diminta, dengan hak orang yang meminta”.⁶ Syarat mutlak pemakaiannya adalah memeriksa nilai kembalian. Jika pemrosesan dilanjutkan padahal impersonation gagal, operasi berikutnya berjalan dengan hak tinggi server sendiri. Dokumentasi resmi menyatakan secara eksplisit: “saat gagal, permintaan klien tidak boleh dijalankan”. Bersama RevertToSelf setelah pekerjaan selesai, tata cara di artikel token impersonation berlaku apa adanya.

sequenceDiagram
    accTitle: Alur pemrosesan permintaan dengan impersonation
    accDescr: Server membaca permintaan dari pipe, mengonfirmasi keberhasilan ImpersonateNamedPipeClient, lalu beroperasi dengan hak klien, dan kembali ke konteksnya sendiri dengan RevertToSelf. Jika impersonation gagal, permintaan ditolak tanpa dijalankan
    participant C as Klien
    participant S as Server
    C->>S: Kirim permintaan
    S->>S: Baca permintaan
    S->>S: ImpersonateNamedPipeClient
    Note over S: Jika gagal, tolak tanpa menjalankan permintaan
    S->>S: Jalankan operasi dengan hak klien
    S->>S: Kembalikan dengan RevertToSelf
    S->>C: Balas hasil

Gambar 7: Konfirmasi keberhasilan impersonation dan RevertToSelf yang andal adalah satu paket. Jika dilanjutkan saat gagal, eksekusi berjalan dengan hak server.

flowchart TB
    accTitle: Empat poin menjaga pipe layanan berhak istimewa
    accDescr: Sisi server mengunci pintu masuk dengan menolak jarak jauh, ACL eksplisit, dan jaminan instance pertama; sisi klien menentukan tingkat impersonation seminimal mungkin agar hak tidak dipinjam server palsu (jika desainnya tidak membiarkan server meminjam hak, batasi ke tingkat identifikasi)
    subgraph sv["Sisi server"]
        r1["PIPE_REJECT_REMOTE_CLIENTS"]
        r2["Batasi yang terhubung dengan ACL"]
        r3["FIRST_PIPE_INSTANCE (hanya yang pertama)"]
    end
    subgraph cl["Sisi klien"]
        r4["Tentukan tingkat impersonation seminimal mungkin"]
    end
    sv --> safe["Pipe sebagai batas hak"]
    cl --> safe

Gambar 8: Pada konfigurasi di mana pipe menjadi batas hak, implementasikan 3 poin sisi server + 1 poin sisi klien sebagai satu set.

6. Jebakan praktis

Balapan urutan startup. Jika klien datang terhubung sebelum server membuat pipe, hasilnya error “pipe tidak ada”. Sisi klien menyertakan “tidak ada → tunggu sebentar lalu coba lagi”. Sebaliknya, prinsip sisi server adalah mulai menunggu dengan ConnectNamedPipe sebelum klien start.⁸

flowchart TB
    accTitle: Alur coba ulang koneksi klien
    accDescr: Buka pipe dengan CreateFile; jika pipe tidak ada, tunggu sebentar lalu coba lagi; jika ERROR_PIPE_BUSY karena semua instance terpakai, tunggu yang kosong dengan WaitNamedPipe lalu coba lagi; jika berhasil, masuk ke komunikasi
    cf["Buka dengan CreateFile"] --> ok{"Hasilnya?"}
    ok -->|"Berhasil"| go["Mulai komunikasi"]
    ok -->|"Pipe tidak ada"| wait1["Tunggu sebentar (server belum start)"]
    ok -->|"ERROR_PIPE_BUSY"| wnp["Tunggu yang kosong dengan WaitNamedPipe"]
    wait1 --> cf
    wnp --> cf

Gambar 9: Penanganan koneksi klien membedakan dua jenis kegagalan, “tidak ada” dan “penuh”, lalu keduanya kembali ke coba ulang.

Mendeteksi putus koneksi. Ketika rekan berakhir, Read/Write gagal dengan ERROR_BROKEN_PIPE dan semacamnya. Itu bukan anomali, melainkan keseharian komunikasi. Server yang mendeteksi putus memanggil DisconnectNamedPipe pada instance dan bersiap untuk koneksi berikutnya; klien terhubung kembali — gagasan “rekoneksi idempoten” di artikel sleep/resume berlaku di sini juga.

Asumsi ukuran pesan. Selain pembacaan terpecah mode pesan (Bab 3), jika “maksimal berapa byte satu pesan” tidak diputuskan sebagai protokol, pesan raksasa dari rekan yang jahat (atau yang bug) dapat menghamburkan memori. Tetapkan batas atas, dan putuskan jika terlampaui; itu yang aman.

Selesainya penulisan dan diterimanya data oleh rekan adalah hal berbeda. Keberhasilan WriteFile tidak berarti aplikasi rekan telah memproses data. Operasi yang membutuhkan kepastian ditanggung oleh desain: konfirmasi lewat pesan respons, dan masukkan korespondensi permintaan-respons ke dalam protokol.

7. Ringkasan

• Named pipe adalah kandidat pertama IPC di mesin yang sama. Alasannya: sama mudahnya seperti I/O berkas, plus terintegrasi dengan model keamanan Windows berupa ACL dan impersonation.
• Pilihan mode: “mode pesan jika permintaan dan respons; mode byte jika sudah ada framing sendiri”. Bahkan dalam mode pesan, penanganan pembacaan terpecah (ERROR_MORE_DATA) tetap diperlukan.
• Beberapa klien: beberapa instance + overlapped, atau async/await di .NET. Untuk yang baru, tipe asinkron .NET lebih lugas.
• Pada pipe yang menjadi batas hak, pakai sebagai satu set: tolak jarak jauh, ACL eksplisit, FIRST_PIPE_INSTANCE (hanya yang pertama), dan minimalkan tingkat impersonation di sisi klien.
• Untuk ImpersonateNamedPipeClient, memeriksa nilai kembalian dan RevertToSelf adalah nyawa.
• Rajut “keseharian komunikasi” — urutan startup, putus koneksi, batas atas pesan, konfirmasi respons — ke dalam desain protokol.

Named pipe adalah API lama, tetapi untuk keperluan “membuat proses saling berbicara di mesin yang sama sambil menghormati batas akun Windows”, ini masih alat yang paling masuk akal. Titik keputusan desain hampir seluruhnya tercakup dalam lingkup artikel ini. Setelah itu, tuliskan protokol sendiri di selembar kertas sebelum masuk ke implementasi.

Artikel terkait

• Bagaimana memilih komunikasi antarproses di Windows — tabel keputusan named pipe / TCP / gRPC / shared memory / COM
• Cara konkret memisahkan “hanya pekerjaan yang membutuhkan hak administrator” di aplikasi Windows
• Menangani token impersonation Windows dengan benar — peminjaman hak per thread dan cara kembali yang aman
• Kedalaman I/O Windows (bagian 2) — I/O sinkron dan asinkron: arti sesungguhnya OVERLAPPED
• Jebakan shared memory dan praktik terbaik di lapangan

Area konsultasi terkait

KomuraSoft LLC menangani desain dan implementasi yang melibatkan komunikasi antarproses — pemisahan layanan dan aplikasi UI, pemisahan hak administrator, dan semacamnya — penggantian IPC yang ada (shared memory, soket sendiri, COM, dan lain-lain) dengan named pipe, serta tinjauan keamanan komunikasi pipe pada layanan berhak istimewa. Konsultasi mulai dari diskusi desain protokol pun dipersilakan.

• Pengembangan aplikasi Windows
• Konsultasi teknis dan tinjauan desain
• Investigasi bug dan analisis akar masalah
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Bagaimana memilah pemakaian named pipe dan TCP (soket localhost)?

Untuk komunikasi antarproses di mesin yang sama, named pipe adalah kandidat pertama. Alasannya ada pada model keamanan. Di tingkat OS, pipe dapat mengontrol siapa yang boleh terhubung lewat Windows security descriptor (ACL). Di sisi server, ImpersonateNamedPipeClient memungkinkan memeriksa dan meminjam akun Windows pihak yang terhubung. Kontrasnya, port TCP localhost dapat dihubungi siapa saja, sehingga identitas rekan harus dipastikan dengan autentikasi sendiri. Di sisi lain, pendekatan berbasis TCP lebih menguntungkan jika komunikasi jarak jauh kemungkinan besar akan menyusul, jika juga perlu berbicara dengan proses di OS lain, atau jika ingin memakai aset protokol yang sudah ada seperti gRPC. Pertimbangan ini juga dijabarkan di artikel tabel keputusan komunikasi antarproses.

Mode byte atau mode pesan, mana yang sebaiknya dipakai?

Jika ingin memperlakukan satu penulisan sebagai satu satuan makna, mode pesan (PIPE_TYPE_MESSAGE+PIPE_READMODE_MESSAGE) lebih nyaman. Sisi penerima dapat membaca dalam satuan yang ditulis pengirim, sehingga batas pesan tidak perlu dikelola sendiri. Mode byte adalah aliran byte tanpa potongan seperti TCP, dan framing (misalnya prefix panjang) harus dirancang sendiri. Jika yang dialirkan sudah protokol yang punya framing (misalnya format serialisasi berpanjang), mode byte tidak bermasalah. Perhatian: bahkan dalam mode pesan, jika buffer terima lebih kecil dari pesan, terjadi pembacaan terpecah (ERROR_MORE_DATA), jadi penanganan itu tetap diperlukan. Mode baca juga pengaturan per handle; yang ditetapkan CreateNamedPipe hanya sisi server. Sisi klien harus menentukan PIPE_READMODE_MESSAGE dengan SetNamedPipeHandleState setelah CreateFile. Di .NET, server menentukan PipeTransmissionMode.Message, dan klien mengatur NamedPipeClientStream.ReadMode ke Message setelah terhubung.

Bagaimana membuat server yang melayani beberapa klien sekaligus?

Named pipe dapat membuat beberapa instance dengan nama yang sama, dan satu instance menangani satu klien. Ada dua bentuk. Yang pertama adalah tipe sinkron: satu thread per klien. Implementasinya lugas, tetapi mengonsumsi thread sebanyak jumlah klien. Yang kedua memakai I/O asinkron dengan FILE_FLAG_OVERLAPPED, lalu sejumlah kecil thread menangani ConnectNamedPipe, ReadFile, dan WriteFile untuk semua instance. Sampel resmi Microsoft juga menunjukkan implementasi yang memproses beberapa instance di satu thread. Di .NET, WaitForConnectionAsync pada NamedPipeServerStream plus async/await membuat tipe asinkron bisa ditulis hampir sama lugasnya dengan tipe sinkron. Untuk implementasi baru, kecuali ada alasan khusus, tipe asinkron .NET yang disarankan.

Apa minimum yang harus dilakukan untuk keamanan named pipe?

Ada empat poin. Pertama, jika koneksi jarak jauh tidak diperlukan, tentukan PIPE_REJECT_REMOTE_CLIENTS agar koneksi lewat jaringan ditolak secara eksplisit. Kedua, tetapkan ACL yang sesuai lewat SECURITY_ATTRIBUTES, dan persempit pengguna serta grup yang boleh terhubung (ACL bawaan terlalu longgar untuk sebagian penggunaan). Ketiga, tentukan FILE_FLAG_FIRST_PIPE_INSTANCE saat membuat instance pertama, agar pembajakan nama — pipe bernama sama dibuat lebih dulu — dapat dideteksi (jangan pasang flag ini pada instance kedua dan seterusnya). Keempat, klien yang hanya ingin diidentifikasi server harus menentukan SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION pada CreateFile, agar server palsu tidak meminjam (meng-impersonate) haknya. Pada konfigurasi broker di mana server melakukan akses sungguhan dengan hak klien, impersonation perlu diizinkan, jadi pembatasan ini dipakai atau tidak tergantung apakah desainnya memang tidak membiarkan server meminjam hak.

Apa yang perlu diwaspadai saat memakai ImpersonateNamedPipeClient?

Yang paling penting adalah memeriksa nilai kembalian. Jika pemrosesan dilanjutkan padahal impersonation gagal, operasi berikutnya berjalan dengan hak proses server sendiri (sering kali tinggi), dan operasi yang seharusnya tidak diizinkan bagi klien ikut lolos. Dokumentasi resmi juga menyatakan secara eksplisit bahwa saat gagal, permintaan klien tidak boleh dijalankan. Impersonation juga berlangsung dalam konteks pesan terakhir yang dibaca dari pipe, jadi harus dipanggil setelah membaca sesuatu, dan setelah pekerjaan selesai harus kembali ke konteks semula dengan RevertToSelf. Mekanisme seputar impersonation (token, tingkat impersonation, SeImpersonatePrivilege) dijelaskan secara rinci di artikel tentang token impersonation.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.