UNIX socket path parsing from /proc is mostly broken

[gianlucaborello]

I just found out our parsing of UNIX sockets in libscap from /proc is bugged:

Behavior 1 (correct)

Here, sysdig is started before running nc:

$ sudo nc -U /var/run/docker.sock
lslsls
HTTP/1.1 400 Bad Request
$

$ sysdig -r trace.scap -A -c echo_fds evt.buffer contains lslsls
------ Write 7B to   ffff88018f91e780->ffff88018f91eb00 /var/run/docker.sock (nc)

lslsls

So the UNIX socket path is correctly displayed

Behavior 2 (bugged)

Here, sysdig is started after running nc:

$ sysdig -r trace2.scap -A -c echo_fds evt.buffer contains lslsls
------ Write 7B to    (nc)

lslsls

The socket name is not recognized because looking in /proc there's no way to discover the other half of the UNIX socket:

$ sudo ls -l /proc/11832/fd
total 0
lrwx------ 1 root root 64 Oct 11 11:28 0 -> /dev/pts/2
lrwx------ 1 root root 64 Oct 11 11:28 1 -> /dev/pts/2
lrwx------ 1 root root 64 Oct 11 11:28 2 -> /dev/pts/2
lrwx------ 1 root root 64 Oct 11 11:28 3 -> socket:[67089]
gianluca@sid:~$

gianluca@sid:~$ sudo cat /proc/net/unix
Num       RefCount Protocol Flags    Type St Inode Path
...
ffff880051a53480: 00000003 00000000 00000000 0001 03 58704 /var/run/docker.sock
ffff880051a53800: 00000003 00000000 00000000 0001 03 67089
...

So this seems more of a bug in /proc (it should show both endpoints connected like in /proc/net/tcp so that the matching should be possible), and of course also lsof is affected, but I'm reporting it here for bookkeeping since it's very annoying when working with the docker API.

[HybridReaverHD]

1758 might be related

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.