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...
The de jure standard location for temporary files is given in the environment variable TMPDIR
.
This variable shall represent a pathname of a directory made available for programs that need a place to create temporary files.
In fact, many systems do not define TMPDIR
. The de facto standard location for temporary files is /tmp
. So check TMPDIR
, and if it is not set, use /tmp
. In a shell script, you can use ${TMPDIR:-/tmp}
, or if you find it more convenient,
if [ -z "$TMPDIR" ]; then TMPDIR=/tmp; fi
or to cope with set -u
: "${TMPDIR:=/tmp}"
You can assume that this location is writable, but it may be world-readable and world-writable, so:
- When you create a regular file, always make sure that you aren't overwriting an existing file, which might not belong to you. Don't use a shell redirection for this. It is not safe to test ownership separately because an adversary may move symbolic links around while your program is running to fool the checks. Additionally you can't rely on a particular name not existing; to prevent a concurrent program from creating a denial of service by creating a file with the same name just before you, use a random name. You can use the
mktemp
utility (widespread, present on GNU, BusyBox, BSD, but not POSIX) or the mkstemp
C library function. Under the hood, open
or creat
must be called with the O_EXCL
flag.
- You can create a directory with
mkdir
. This is secure against ownership trickery stealing, because that won't reuse an existing file, but it is prone to the same denial of service as regular files, so you should use a random name. mktemp -d
is a fine way to do this.
- You can create a socket (there's no standard shell utility for that). Like the directory case, it is secure against ownership trickery but not against denial of service.
Linux honors permissions on named sockets, but there are Unix variants that don't. This is why sockets in /tmp
are usually created in subdirectories.
Programs that create a subdirectory of /tmp
(or $TMPDIR
if set) and create a named socket there include X11 servers, ssh-agent, gpg-agent, KDE, emacs, … (that's just the ones that exist on the machine where I'm posting this). As you can see, you'll be in good company.
Best Answer
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.