18

I want to know how to use something that behaves like Unix Domain Socket on Windows.

The behaviour is: A process will be a "server" and receive connections from other processes and it can keep and use connections from different processes, as a TCP socket does.

IP socket is not a solution, because it requires to choose a port, processes from other applications may need the chosen port, and the open port may be seen in the network.
I do not know if named pipes can receive and keep multiple clients, but I did not see how to distinguish different clients. And it does not provide a way to wait data from multiple connections with something like select.

An old question says about using named pipes, but it does not explain how to use named pipes to get the desired behaviour. AF_UNIX in windows
I did not see how to get the handle of a specific client.

Community
  • 1
  • 1
Squall
  • 4,344
  • 7
  • 37
  • 46

3 Answers3

17

Windows has recently (Windows 10 Insider build 17063) implemented support for AF_UNIX, so you can use it in future windows builds.

However not all of it is implemented, the below features don't work.

  • AF_UNIX datagram (SOCK_DGRAM) or sequence packet (SOCK_SEQPACKET) socket type.
  • Ancillary data: Linux's unix socket implementation supports passing ancillary data such as passing file descriptors (SCM_RIGHTS) or credentials (‘SCM_CREDENTIALS`) over the socket. There is no support for ancillary data in the Windows unix socket implementation.
  • Autobind feature (see the section on ‘sockaddr_un’ for details).
  • socketpair: socketpair socket API is not supported in Winsock 2.0.

Source: https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

TheWhoAreYouPerson
  • 181
  • 2
  • 7
3

Probably not the answer you want to hear, but COM is one of several standard mechanisms to achieve inter-process communication in Windows. It has it's issues that annoy developers - but it works quite well for all the requirements you listed.

As for IP sockets, you mentioned the issue of "can be seen in the network". This is not the case if you just simply bind your server socket to the localhost address (127.0.0.1). (2021 disclaimer - there is a potential vulnerability - see comments below).

SOCKET s;
const DWORD LOCAL_HOST_IP = 0x7f000001; // 127.0.0.1
sockaddr_in addrLocal = {};
   
s = socket(AF_INET, SOCK_STREAM, 0);
addrLocal.sin_family = AF_INET;
addrLocal.sin_port = htons(YOUR_APPLICATION_PORT);
addrLocal.sin_addr.s_addr = htonl(LOCAL_HOST_IP);
s = SOCKET(AF_INET, SOCK_STREAM, 0);
bind(s, (sockadr*)&addrLocal, sizeof(addrLocal));
selbie
  • 100,020
  • 15
  • 103
  • 173
  • 2
    Binding to localhost, though, isn't 100% safe because of Javascript (which can send HTTP requests to ports on localhost, even if it was loaded from a public website). This has bitten a number of developers in recent years, including some security folk who should know better. – al45tair Jan 20 '20 at 18:48
  • @alastair Where did you get that from? JavaScript requests are not any different from other requests. If a socket is bound to localhost, JavaScript requests cannot reach it if they originate from non-localhost. – Felix Schütz Sep 10 '21 at 13:12
  • 2
    @FelixSchütz - alstair is actually correct. While a malicious attacker can't remotely connect to my sockets running on localhost, javascript running locally in my browser absolutely can. For example, let's say you visit www.badbuys.com. All they have to do is have a dns entry to localhost.badguys.com that points to 127.0.0.1 and their web page can scan port scan your computer. [ebay was actually doing exactly this](https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/) - supposedly for scanning for compromised machines. – selbie Sep 10 '21 at 17:50
  • 1
    You could possibly mitigate the localhost issue by having a custom protocol that isn't HTTP or websocket based. And pick random ports. But you can still be port scanned and/or have a page disrupt you. [Dell computers had a huge security hole](https://billdemirkapi.me/remote-code-execution-on-most-dell-computers/) around this. – selbie Sep 10 '21 at 17:55
  • 1
    My general advice now is that if you need a localhost socket, don't have it be persistently listening. Open it in listening mode as soon as you need it and have some security on incoming connections (e.g. a locally generated password or security token is validated for incoming connections). – selbie Sep 10 '21 at 18:00
  • To be honest, on a multiuser system (and increasingly that means everything, even Windows), you should have some kind of security token on things that are bound to localhost anyway. Unless it's just vending totally harmless information, possibly (but realise that that could be abused to construct profiles/advertising identifiers and so on). – al45tair Sep 12 '21 at 18:25
  • So when CORS is correctly configured, JavaScript requests can only scan ports on localhost (although some browsers fixed this nowadays, as far as I know). Knowing whether a socket is listening on a port is much less than actually communicating with the socket, which I thought @alastair meant. – Felix Schütz Sep 13 '21 at 11:33
  • 1
    @FelixSchütz The problem is that the Javascript you've been served may be malicious and may come from a malicious domain, whose CORS setting and DNS is deliberately set up so that the Javascript code will have access to localhost. CORS might protect against script injection attacks; it doesn't protect against malicious stuff intentionally served from the actual server. – al45tair Sep 14 '21 at 12:39
  • @alastair The CORS setting of the malicious domain does not control whether the JavaScript code has access to localhost, that is only decided by the CORS header served by localhost. – Felix Schütz Sep 14 '21 at 13:34
0

I have found the answer.

The big difference is that the handle the waits a connection is the same that does communications to a client. I would have to create a new named pipe for the server to wait for the next client.

References:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365799%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365588%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365603%28v=vs.85%29.aspx

Squall
  • 4,344
  • 7
  • 37
  • 46