Как узнать, какая программа находится на другом конце локального сокета?

Question

Процесс в моей системе Linux, говорит мне strace, говорит о сокете с файловым дескриптором 10. lsof говорит мне, что это сокет unix с инодом 11085, а netstat также сообщает мне, что инод 11085 является потоковым сокетом и что это связано.

Учитывая, что у этого процесса нет других потоков, в системе должен быть другой процесс, подключенный к другому концу этого сокета. Как мне узнать что это такое?

Обновление:

Здесь есть некоторое освещение от автора lsof здесь . По сути, кажется, что Linux просто не предоставляет эту информацию.

Answer 1

ss -p

скажет. (При условии, что сокет не принадлежит самому ядру.)

Answer 2

Помогает ли netstat -p?

С Manpage:

  -p,
  --program Show the PID and name of the program to which each socket belongs.

Answer 3

Как насчет этого: grep 11085 /proc/net/unix. Предполагая, что в строке с интересующим вас индексом присутствует непустой путь, grep для этого пути в /proc/net/unix, чтобы найти индекс для другого конца соединения, затем используйте метод @ffectivejelly для сопоставить другой индекс с pid.

Ключевым моментом здесь является тот факт, что каждый из двух подключенных сокетов будет иметь различный номер инода.

Answer 4

Я написал инструмент , который использует метод gdb для надежного получения информации о равноправном устройстве сокетов, символы отладки ядра не нужны.

Чтобы подключить процесс к указанному сокету, передайте ему номер инода:

# socket_peer 11085
3703 thunderbird 

Чтобы выяснить для всех процессов одновременно, используйте netstat_unix, он добавляет столбец к выводу netstat:

# netstat_unix
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Peer PID/Program name  Path
unix  3      [ ]         STREAM     CONNECTED     6825     982/Xorg             1497/compiz            /tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     6824     1497/compiz          982/Xorg                 
unix  3      [ ]         SEQPACKET  CONNECTED     207142   3770/chromium-brows  17783/UMA-Session-R       
unix  3      [ ]         STREAM     CONNECTED     204903   1523/pulseaudio      3703/thunderbird       
unix  3      [ ]         STREAM     CONNECTED     204902   3703/thunderbird     1523/pulseaudio           
unix  3      [ ]         STREAM     CONNECTED     204666   1523/pulseaudio      3703/thunderbird       
...

Попробуйте netstat_unix --dump, если вам нужен вывод, который легко анализировать.
Подробнее см. https://github.com/lemonsqueeze/unix_sockets_peers.

Для справки, inode + 1 / -1 взломать не является надежным. Он работает большую часть времени, но не удастся или (что еще хуже) вернет неправильный сокет, если вам не повезло.

Answer 5

Я заметил, что:

Индекс fd, который вызывал connect() на стороне клиента, всегда на единицу больше, чем тот, который вы получили после вызова accept() на стороне сервера.

Пример вывода из моей проги:

client_fd=4
/proc/4436/fd/4
inode=3072
is socket
node: 3072 socket: /tmp/unix.socket
f0be8960: 00000003 00000000 00000000 0001 03  3072 /tmp/unix.socket

/proc/9293/fd/43
fd:43
inode=3073
is socket
node: 3073 socket: 
f0be81e0: 00000003 00000000 00000000 0001 03  3073

Связанный путь не отображается в /proc/net/unix.

YMMV и я не исследовали основную механику.

Answer 6

Похоже, если вы действительно в отчаянии, вы можете получить эту информацию прямо из памяти ядра Linux, используя некоторый отладчик ядра. С помощью инструмента RHEL5 "crash":

• получить несжатый vmlinux образ (например, установить kernel-debuginfo об / мин или извлечь vmlinux файл из этих об / мин)
• пробег crash /path/to/vmlinux
• net -s 12345 перечисляет все сокеты для PID 12345
• найдите интересующий сокет (должен быть семейства / типа UNIX:STREAM) и обратите внимание на его значение SOCK:
  • PID: 12345 TASK: e903d000 CPU: 0 COMMAND: "someapp"
  • FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT DESTINATION-PORT
  • 36 cadd0240 c8a64040 UNIX:STREAM
• у вас теперь есть адрес unix_sock struct для этого сокета
  • в основном unix_sock.peer.name - это структура имени другого конца сокета
  • распечатать с помощью: p *(*(*((struct unix_sock*)( (struct unix_sock*)0xc8a64040)->peer)).addr).name

Действительно печально, что эта информация напрямую не экспортируется в пользовательское пространство.

Answer 7

Если по какой-то причине вам не повезло с соответствующими параметрами lsof и netstat, вы также можете сделать следующее:

find /proc -lname '*11085*' 2> /dev/null

Answer 8

lsof | grep 11085

lsof должен выполняться от имени пользователя root.

Я экспериментировал с lsof в моей системе Linux, и lsof -U показывает, что все числа в столбце NODE уникальны.