32

On Unix systems path names have usually virtually no length limitation (well, 4096 characters on Linux)... except for socket files paths which are limited to around 100 characters (107 characters on Linux).

  • First question: why such a low limitation?

I've checked that it seems possible to work around this limitation by changing the current working directory and creating in various directories several socket files all using the same path ./myfile.sock: the client applications seem to correctly connect to the expected server processes even-though lsof shows all of them listening on the same socket file path.

  • Is this workaround reliable or was I just lucky?
  • Is this behavior specific to Linux or may this workaround be applicable to other Unixes as well?
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
WhiteWinterWolf
  • 2,851
  • 2
  • 21
  • 37

2 Answers2

30

Compatibility with other platforms, or compatibility with older stuff to avoid overruns while using snprintf() and strncpy().

Michael Kerrisk explain in his book at the page 1165 - Chapter 57, Sockets: Unix domain :

SUSv3 doesn’t specify the size of the sun_path field. Early BSD implementations used 108 and 104 bytes, and one contemporary implementation (HP-UX 11) uses 92 bytes. Portable applications should code to this lower value, and use snprintf() or strncpy() to avoid buffer overruns when writing into this field.

Docker guys even made fun of it, because some sockets were 110 characters long:

This is why LINUX uses a 108 char socket. Could this be changed? Of course. And this, is the reason why in the first place this limitation was created on older Operating Systems:

Quoting the answer:

It was to match the space available in a handy kernel data structure.

Quoting "The Design and Implementation of the 4.4BSD Operating System" by McKusick et. al. (page 369):

The memory management facilities revolve around a data structure called an mbuf. Mbufs, or memory buffers, are 128 bytes long, with 100 or 108 bytes of this space reserved for data storage.

Other OSs(unix domain sockets):

  • 1
    SUSv3 XNET was silent because there not consensus on the issue. – fpmurphy May 24 '17 at 18:16
  • Do you have any link to proof your point of view? –  May 24 '17 at 18:39
  • Thanks for this answer. Is it reliable to use several socket files bearing identical names relative to different working directories (for instance, create a sockets file named `./my.socket` below directory `A/`, and another socket file also named `./my.socket` below directory `B/`)? `lsof` doesn't make any distinction between the two socket files, however it still seem to work but I wonder if this is just because I'm lucky. This would be a good workaround to create socket files below a path which is already longer than the allowed size. – WhiteWinterWolf May 24 '17 at 18:57
  • Searching for unix sockets on my mailserver, seems to bring full path name: `lsof -U| grep amavis` (newline) `amavis-se 2708 zimbra 17u unix 0xffff8806c0a95400 0t0 310330411 /opt/zimbra/data/tmp/amavisd-zmq.sock` –  May 24 '17 at 19:19
  • Yes, I know this is unusual, hence my question here ;) ! For what I tested, relative names work, but it still seems odd to me... but it works. My application is not system-wide, so socket files are either stored with all other application data in a user-controlled location, which is strongly preferred but with a potentially too long path, or I can clutter `/tmp` with tons of uniquely named undeleted directories each containing a single socket file (utterly ugly, but portable and secure). – WhiteWinterWolf May 24 '17 at 19:38
  • You could shorten the name to `my.sock` and you will have plenty of 101 characters to deal with :) –  May 24 '17 at 19:47
  • @WhiteWinterWolf Not sure if this is part of the Filesystem Hierarchy Standard or not, but on Fedora at least the correct place for a user-specific named socket would be in `/run/user///my.socket` – BenjiWiebe May 25 '17 at 02:56
  • @nwildner. I was a voting member of XNET for a number of years. – fpmurphy May 25 '17 at 04:15
  • @fpmurphy1 and i should trust that just because you are saying this? I cant even check if you are a real person at your profile.... No offense, but if you don't have a link to make you theory valid, it will not be part of the answer. –  May 25 '17 at 10:37
  • Just a quick note to tell you I have investigated a bit the use of relative path for socket files (see my answer). Unless I missed something, it seems safe to me as, as per my understanding, the OS internally relies on inodes and not on path to identify the socket file. – WhiteWinterWolf May 25 '17 at 11:04
  • @nwildner. If you had bothered to look at my profile, you would have seen it contains a link to my technical website which in turn contains a link to my LinkedIn profile. You do have a LinkedIn account? Then do an Internet search on my full name + "Single UNIX Specification" – fpmurphy May 25 '17 at 16:51
  • Will i find any proof of what started this discussion? "SUSv3 XNET was sitent because there not consensus on the issue"... –  May 25 '17 at 16:57
8

Regarding the why, nwildner already wrote an excellent answer.

Here I will just focus on the how and the relative path usage.

Internally, while socket file can also be looked up by name (I guess), they are usually looked up by inode. In Linux, this lookup is ensured by the function unix_find_socket_byinode() defined in net/unix/af_unix.c.

This can be easily checked as follow:

  • Create two directories A/ and B/.
  • Under each directory, make a process listen on socket files bearing the same name. With socat you would use a command such as:
$ socat UNIX-LISTEN:./my.sock -
  • Now exchange the socket files by moving A/my.sock to B/ and vice-versa.
  • From now on, if client application connects to A/my.sock it will contact the server B, and if it connects to B/my.sock it will contact the server A (note though that when the communication ends, the server process may legitimately delete what it thinks to be its own socket file).

I checked this behavior on a handful of Unix systems (Linux Debian, FreeBSD and OpenIndiana to get some diversity), so this behavior seems to be at least wide-spread, if not standard.

Absolute paths are usually used as a convention between the client and the server processes, as the client process may not otherwise know how to establish the initial communication with the server.

However, if this initial communication is not an issue, it seems therefore safe to use relative paths for socket files creation, allowing to avoid path length issues when the socket file location is not directly controlled by the server process.

WhiteWinterWolf
  • 2,851
  • 2
  • 21
  • 37