There's nothing wrong with creating the socket in a dotfile or dotdir in the home directory of the user, if the user is not some kind of special, system user. The only problem would be with the home directory shared between multiple machines over nfs, but that could be easily worked around by including the hostname in the name of the socket.
On Linux/Ubuntu you could also use "abstract" Unix domain sockets, which don't use any path or inode in the filesystem. Abstract unix sockets are those whose address/path starts with a NUL byte:
abstract: an abstract socket address is distinguished (from a pathname socket) by the fact that
sun_path is a null byte (
The socket's address in this namespace is given by the additional
sun_path that are covered by the specified length of the
address structure. (Null bytes in the name have no special significance.) The name has no connection with filesystem pathnames. When
the address of an abstract socket is returned, the returned
is greater than
sizeof(sa_family_t) (i.e., greater than 2), and the
name of the socket is contained in the first
(addrlen - sizeof(sa_family_t)) bytes of
When displayed for or entered by the user, the NUL bytes in a abstract Unix socket address are usually replaced with
@s. Many programs get that horribly wrong, as they don't escape regular
@s in any way and/or assume that only the first byte could be NUL.
Unlike regular Unix socket paths, abstract Unix socket names have different semantics, as anybody can bind to them (if the name is not already taken), and anybody can connect to them.
Instead of relying on file/directory permission to restrict who can connect to your socket, and assuming that eg. only root could create sockets inside some directory, you should check the peer's credential with
getsockopt(SO_PEERCRED) (to get the uid/pid of who connected or bound the peer), or the
SCM_CREDENTIALS ancillary message (the get the uid/pid of who sent a message over the socket).
This (replacing the usual file permission checks) is also the only sane use of