Named pipes

Of the three mechanisms this level covers, named pipes are the one closest to a file: something a server creates with a name, and something a client opens using that name, exchanging data through it much like reading and writing a file — except what's on the other end is another live process, not a disk.

The shape of a named pipe

A server calls CreateNamedPipe with a name like \\.\pipe\MyService and a set of options: byte-stream or message-oriented framing, duplex or one-way, and how many simultaneous instances to allow. A client then opens that name — locally with \\.\pipe\MyService, or across the network as \\ServerName\pipe\MyService — and from that point on, both sides read and write through what behaves like an ordinary file handle.

Two details make named pipes more capable than they first appear:

• Multiple instances. A server can create several instances of the same named pipe, letting several clients connect simultaneously, each with its own independent buffers and state, without them interfering with each other. The pipe name is shared; the conversation is not.
• Message mode vs. byte mode. A byte-mode pipe is an undifferentiated stream, like a plain file. A message-mode pipe preserves boundaries: if the writer sends three separate messages, the reader sees three separate reads, even if the underlying bytes could otherwise have been read as one blob. This removes an entire class of "where does one message end and the next begin" bugs that byte-oriented protocols have to solve themselves.

Impersonation: the feature that makes pipes useful for privilege boundaries

The single most important thing a named pipe server can do that a plain file can't: impersonation. A server thread can call ImpersonateNamedPipeClient to temporarily adopt the connecting client's security context for the duration of a request — meaning any access check the server performs while impersonating is evaluated as if the client, not the server, were asking.

This is exactly the mechanism that lets a privileged service safely perform an operation on behalf of a less-privileged caller without simply trusting whatever the caller claims about itself: the service can impersonate the client, attempt the operation, and let the ordinary access-check machinery decide whether the client's own token would have allowed it — cleanly reusing the security model instead of reimplementing authorization logic inside the service.

A worked example: a GUI talking to a privileged helper

A common, genuinely representative Windows pattern: an ordinary, unprivileged desktop application needs one specific privileged operation done (say, writing to a protected registry key), so it doesn't run elevated itself — instead, a small privileged helper service listens on a named pipe, the GUI connects and sends a request, and the service either performs the operation under its own elevated identity after validating the request, or impersonates the caller first if the operation should be constrained to what that specific user is allowed to do. Either way, the GUI process itself never needs elevated rights, which keeps its attack surface — and the blast radius if it's ever compromised — much smaller.

A common mistake

Treating a named pipe as "just a way to send text between two programs" undersells what it actually offers: full-duplex communication, message framing, per-instance state for multiple simultaneous clients, network transparency without code changes, and — critically — a real security boundary through impersonation. Two programs writing raw bytes to a shared file would have to reimplement most of this themselves; named pipes get it from the OS for free.

Where this connects

• RPC & COM foundations frequently uses named pipes (ncacn_np, in RPC's own naming) as one of several possible transports underneath a higher-level procedure-call interface.
• Security descriptors & ACLs covers exactly how a pipe's own security descriptor controls who is even allowed to open it in the first place, before impersonation ever comes into play.