HP-UX for example ignores permissions on the socket file.
Note that the docs are talking about permissions on the socket file. All implementations respect permissions on the parent directories - a portable program must make sockets in a private directory, rather than rely on making sockets with restrictive permissions (via umask) in a public directory.
You're confusing two things here.
A socket is a file descriptor - a handle - given to a program so that it can use a network connection in almost the same way it uses files. The socket API is protocol-independent; sockets can be created for IPv4 connections or IPv6 ones, but (given kernel support) also for things like DECnet, AppleTalk, or read Ethernet.
Since the socket API is fairly easy to use but since talking to a process on the same machine using an actual network protocol is rather inefficient, at some point the UNIX domain socket was created to allow use of the socket API without that inefficiency. It also adds some extra features; e.g., it is possible to pass file descriptors to another process over a UNIX domain socket.
When one uses UNIX domain sockets, both processes still hold a socket, one for each side of the connection. The use of the socket is no different from, say, IPv4 sockets, apart from the initial connection setup.
One thing the socket API cannot do without is an address; it is not possible to create a socket without passing it an address to talk to, and this is no different for the UNIX domain socket. Since it's UNIX, where everything is a file anyway, it was decided to make these addresses look like filenames. And since we're already doing that, it makes sense to make these addresses appear in the file system, since that makes it easy to spot them.
Unfortunately, the name given to these things in the file system was also 'UNIX domain socket' (or at least, that's what people started calling them). They're not the actual sockets in the sense of the socket API, however; they couldn't be, since those are just a number. As such, their counterpart in an IPv4 socket is not that number, but instead the IP address and port number of the peer you're talking to.
Occasionally, I'll add that since the socket API doesn't deal with files directly, these filesystem representations aren't strictly necessary. Indeed, Linux has a concept of 'anonymous UNIX domain sockets', which are just that: UNIX domain sockets without any link in the filesystem...
Best Answer
They are commonly found in
/tmpor a subdirectory thereof. Note that everything in/tmpis subject to erasure at shutdown -- not that it necessarily is erased, just beware that it can be, so if you use that, check if you have to create your subdirectory each time. You will want to use a subdirectory if you want to restrict access via permissions, since/tmpis world readable./runand/var/run(which may be symlinked together) are used in a similar way, but they are generally mounted as tmpfs filesystems -- meaning they are created at boot and reside in memory, not on disk (so do not use that as a place to dump copious amounts of data). For a runtime socket, it is probably a good choice.Note that
/run, and all of the other directories mentioned here except/tmp, are only writable by root. For a system process, this is fine, but if the application may be run by a non-privileged user, you either want to use/tmpor create a permanent directory somewhere and set permissions on that, or use a location in the user's $HOME.It is possible to create a directory in
/usr/share(or/usr/local/share) during installation. Directories and contents there are not potentially reaped across boots as they would be in/tmpor/run. However, as jordanm points out in the comments,/usrmay be mounted read-only and the linux filesystem hierarchy guidelines reflect this. Of course, it can't be read-only when your application is installed, so if you are comfortable creating a socket there then, you can leave it and use it later (you will still be able to write to the socket even though the file is read-only).If you want somewhere persistent across boots that won't get mounted read-only,
/etcis a fairly safe bet, since this is often used for system-wide configurations and re-configurations. OTOH, it is possible to have systems where the device underlying the entire root filesystem is read-only (e.g., embedded systems), with /tmp and /run on another device (probably: tmpfs in memory). So the two most robust strategies would seem to be:Install the socket to a permanent location when the application is installed.
Create a directory in
/runor/var/runat runtime and put the socket there.Do the same thing only in
/tmp.The advantage of the first one is that no matter what, once the app is installed, you'll have a socket to use. The advantage of the second one is that it may be more conducive to sane programming. The advantage of the third is it does not require superuser privileges. It should be easy to switch from one implementation to another if you change your mind later.
Finally, as BatchyX brought up, you should at least offer a configuration option for this, falling back on your choice of default.