Can't change NamedPipe permissions with Windows

[apirila]

Version

16.15.1

Platform

Windows 11

Subsystem

net

What steps will reproduce the bug?

The API for creating a named pipe in Windows does not allow setting permissions of the named pipe and by default pipes are readable by everyone. This makes secure programming very difficult.

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

No response

What do you see instead?

Either default permissions should be set to current user only or an API should be provided to set the permissions.

Additional information

No response

[bnoordhuis]

The API for creating a named pipe in Windows

For my understanding: what specific API inside node are you referring to?

[apirila]

I created Windows named pipes like this:

var net = require('net');

var PIPE_NAME = "mypipe";
var PIPE_PATH = "\\\\.\\pipe\\" + PIPE_NAME;

var L = console.log;

var server = net.createServer(function(stream) {
    L('Server: on connection')

    stream.on('data', function(c) {
        L('Server: on data:', c.toString());
    });

    stream.on('end', function() {
        L('Server: on end')
        server.close();
    });

    stream.write('Take it easy!');
});

server.on('close',function(){
    L('Server: on close');
})

server.listen(PIPE_PATH,function(){
    L('Server: on listening');
})

// == Client part == //
var client = net.connect(PIPE_PATH, function() {
    L('Client: on connection');
})

client.on('data', function(data) {
    L('Client: on data:', data.toString());
    client.end('Thanks!');
});

client.on('end', function() {
    L('Client: on end');
})

Example is from here: https://stackoverflow.com/questions/11750041/how-to-create-a-named-pipe-in-node-js

The problem is that, AFAIK, in Windows named pipes are created using the network subsystem, not using files.

[bnoordhuis]

Node (well, libuv) calls CreateNamedPipe() with the WRITE_DAC (but not WRITE_OWNER) flag and default security attributes, meaning:

The ACLs in the default security descriptor for a named pipe grant full control to the LocalSystem account, administrators, and the creator owner. They also grant read access to members of the Everyone group and the anonymous account.

Excluding some of those may be reasonable (or maybe not, I'm undecided) but as node has worked this way since basically forever any change in default behavior risks breaking existing libraries or applications, so we're unlikely to make that change.

(As well, since you're the first one to bring this up, it seems like a safe bet the default is working fine for most users.)

An opt-in could work but you'll have to pursue that by modifying libuv (open an issue first to hash out the details) and then changing node to make use of the new libuv API.

If you don't plan on working on that, fair, but then please close the issue.

[bnoordhuis]

I assume the lack of reply means you're not intending to pursue this. I'll close out the issue.

[SlugFiller]

To anyone reading this from the future, the correct solution is:

server.listen({
    path: PIPE_PATH,
    readableAll: true/false,
    writableAll: true/false,
},function(){
    L('Server: on listening');
})

This was implemented in 531b4be, i.e. 5 years before this issue was even posted.
It's also a duplicate of #30823 which was also closed as "wontfix" 4 years prior, and #19154, which is the original issue.

However, there IS a bug, which could justify reopening this issue. The bug is in this line in lib/net.js. It does not set the permissions if both readableAll and writableAll are set to false. However, the default permissions on Windows, when no permissions are set, are readableAll: true, writableAll: false, which means that even if readableAll: false is explicitly set, no call to fchmod is made.

A workaround is to use

server.listen(PIPE_PATH,function(){
    server._handle.fchmod(0);
    L('Server: on listening');
})

However, this is not a pretty solution, since it relies on internal implementation details that are not part of the public API.

A better solution would be if Server.prototype.listen had different handling for the case where readableAll is false and where it's undefined.

[Pricer187]

What you talking about

…

On Mon, Jun 8, 2026 at 2:51 AM Jingchao Feng ***@***.***> wrote: *fjch1997* left a comment (nodejs/node#47086) <#47086 (comment)> A workaround is to use server.listen(PIPE_PATH,function(){ server._handle.fchmod(0); L('Server: on listening'); }) However, this is not a pretty solution, since it relies on internal implementation details that are not part of the public API. A better solution would be if Server.prototype.listen had different handling for the case where readableAll is false and where it's undefined. There is no need to use _handle. This works server.listen(PIPE_PATH,function(){ fs.chmod(PIPE_PATH, 0, e => console.log(e ?? "chmod success")); L('Server: on listening'); }) — Reply to this email directly, view it on GitHub <#47086?email_source=notifications&email_token=BJKG3LCBVYOXGKO2TKAMVX346ZO75A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGYYTIMJZGA2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4646141904>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJKG3LG43NCUV7CCOLY5QAL46ZO75AVCNFSM6AAAAACZ6TNMTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMNBWGE2DCOJQGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>