Networking notes - sockety things

For other network related things, see: Networking basics - General Layer 2 mostly - On MACs and EUIs · ARP notes · Spanning tree notes · Bridging notes · DHCP notes · Layer 2 unsorted notes Layer 3 (IP mostly) - sockety things · IPv4 notes · IPv6 notes Firewalling and other packet stuff wireshark and tshark notes · tcpdump notes · nmap notes · other network tools Also: Network wiring notes - 8P8C / RJ45 Network wiring notes - Power over Ethernet Wireless communication IO and wired communication More technical VPN notes

Sockety things

There is a POSIX socket API, evolved from an earlier Berkeley API.

Technically it was a standardization of early TCP, that also allowed wider set of protocols.

Named sockets

Named sockets are a somewhat ambiguous name, in that some people use them to refer to abstract sockets, some to named pipes.

Local sockets / unix domain sockets

POSIX calls it PF_LOCAL

BSD calls it PF_UNIX, which is #define'd to the same thing.

Both ends of such a socket connect, via code[1], to what to your code looks like a file on the filesystem.

On the code side it presents a fairly normal socket interface - you can e.g. send() and recv()

Security is mostly the filesystem permissions to that socket file, when you open() it.

Since the API behind this is is essentially its own tiny subsystem, it fundamentally cannot be network-routed. Since it does not involve IP, there are no ports

Local sockets are simpler system and can be a little lower overhead than localhost networking.

Local sockets are essentially a special case within what is still the network stack (but not as standard, e.g. windows only eventually implemented it(verify)). (There are other local-only things, such as localhost IP, in the latter case that is because the network refuses to route, whereas local sockets aren't even IP to be able to route it)

This makes them useful for local IPC (both because it's fast, and because you can't accidentally open it up to the network with config handing parameters to listen())

Note that it is also distinct from named pipes.

See also:

• https://en.wikipedia.org/wiki/Unix_domain_socket

Abstract sockets

Abstract sockets are local sockets (AF_LOCAL/AF_UNIX, see previous section) but in the special-cased abstract namespace.

The abstract namespace basically means that it lets you bind sockets to names that are managed via the kernel, rather than filenames on a filesystem (as with regular local sockets).

The way this is implemented in linux allows you to create a local socket as per usual AF_LOCAL way, when you hand in a path string that starts with a 0x00 (null) byte.

So basically, you bind() or connect() to something like "\x00myname"

Upsides:

• you can avoid existing socket files on filesystem
• you don't have to clean up socket files (kernel removes them when last reference closes)

Caveats:

• no permission limitations at all now
• linux-only

This makes them useful for IPC on linux, but only when you trust everything and everyone on the host.

Support: CHECKME

at the very least 2.6 kernels, and enabled.

recent kernels can be assumed to have it(verify), namespaces have been important for a while.

See also:

• http://man7.org/linux/man-pages/man7/unix.7.html

Named pipes

A special kind of filesystem entry.

Similar to domain sockets in that they are a filesystem thing for local communication.

Different in that they do not present a socket interface at all, just a FIFO-style bytestream, to whatever other process also opens it that file.

Created with mkfifo (syscall and utility share the same name)