Can't change NamedPipe permissions with Windows #47086

Activity

1. bnoordhuis

   added

   windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.

   on Mar 14, 2023
2. bnoordhuis commented on Mar 14, 2023

   

   bnoordhuis

   on Mar 14, 2023

   Member

   More actions

   The API for creating a named pipe in Windows

   For my understanding: what specific API inside node are you referring to?
3. apirila commented on Mar 14, 2023

   

   apirila

   on Mar 14, 2023

   Author

   More actions

   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.
4. bnoordhuis commented on Mar 14, 2023

   

   bnoordhuis

   on Mar 14, 2023

   Member

   More actions

   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.
5. bnoordhuis commented on Mar 21, 2023

   

   bnoordhuis

   on Mar 21, 2023

   Member

   More actions

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

   closed this as not plannedon Mar 21, 2023
7. SlugFiller commented on Jan 22, 2026

   

   SlugFiller

   on Jan 22, 2026

   Last edited by SlugFiller

   More actions

   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.

   ❤️React with ❤️1Reacted by Jingchao Feng
8. Pricer187 commented on Jun 8, 2026

   

   Pricer187

   on Jun 8, 2026 via email

   More actions

   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: ***@***.***>