как узнать полный путь команды от результата lsof-i

Это, похоже, было проблемой синхронизации при загрузке - значение rootdelay = 8 на опциях ядра в моем grub.conf было изменено на rootdelay = 10, и сейчас все работает, как ожидалось. Кажется, что машина не обнаружила все разделы на USB-накопителе к тому моменту, когда она начала загрузку.

Я создал еще одно правило udev, чтобы отобразить мой USB stick/dev/sdu с помощью метки ПРОИЗВОДИТЕЛЬ, найденной udevadm, и все хорошо.

FS поступает из регистра дополнительного сегмента с именем FS в архитектуре 386 (конец второго абзаца).

Я предполагаю, что после DS для сегмента данных и ES для Extra Segment корпорация Intel просто перешла к следующим символам алфавита (FS, GS). Регистр 386 можно увидеть на вики-странице , на рисунке справа.

Из источника ядра Linux в моей системе Linux Mint ( arch/x86/include/asm/uaccess.h ):

/*
 * The fs value determines whether argument validity checking should be
 * performed or not.  If get_fs() == USER_DS, checking is performed, with
 * get_fs() == KERNEL_DS, checking is bypassed.
 *
 * For historical reasons, these macros are grossly misnamed.
 */

#define MAKE_MM_SEG(s)  ((mm_segment_t) { (s) })

#define KERNEL_DS       MAKE_MM_SEG(-1UL)
#define USER_DS         MAKE_MM_SEG(TASK_SIZE_MAX)

#define get_ds()        (KERNEL_DS)
#define get_fs()        (current_thread_info()->addr_limit)
#define set_fs(x)       (current_thread_info()->addr_limit = (x))

Одним из способов может быть проверка файлов, открытых этим процессом. Из типов, указанных в столбце FD в lsof :

FD         is the File Descriptor number of the file or:

               cwd  current working directory;
               ...
               txt  program text (code and data);

Итак, попробуйте:

lsof -a -d txt -p 212548

Для сценариев это показывает путь используемого интерпретатора (например, /bin/bash ). Для сценариев оболочки файл сценария, казалось, был открыт на fd 255 в моей системе, но для сценариев Perl в выходных данных lsof вообще не было упоминания файла сценария.

Сам по себе lsof -i выводит только информацию из Интернета. Вы можете добавить информацию о файле (или показать, что вместо ), используя параметр -d . Например:

lsof -d txt | grep -E '/httpd.pl$'

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

Этот файл, конечно же, должен быть исполняемым, но и совместно используемые библиотеки, которые он загружает, тоже должны быть. В действительно патологическом случае у вас может быть программа, запускаемая из сценария (например, написанного на Python), который загружает общие библиотеки и переименовывает себя в списке процессов.

Согласно ветке CentOS Suspicious Process httpd.pl , из сценария PHP был запущен процесс, который называл себя httpd.pl :

Для всех, кому было интересно. Это был бэкдор, установленный оболочкой php. уборка просто не поймала его в первом раунде.

Другой поток, Подопытный процесс, запущенный на сервере CentOS , дает более подробную информацию:

httpd.pl - это поддельный процесс, который запускает perl.

Обычно это бэкдор, настраиваемый оболочкой php, который будет загружен где-то на веб-сайт.

Дополнительная литература:

• Как процесс может иметь другое имя в выводе ps?
• изменить имя процесса без изменения argv [0] в Linux

Это httpd.pl , это имя процесса. Он инициализируется базовым именем файла, который последний раз выполнялся процессом, но также может быть изменен другими способами.

В perl достаточно присвоить значение $ 0 :

$ perl -e '$0 = "httpd.pl"; sleep 10' & ps -fp $!
[2] 11954
UID        PID  PPID  C STIME TTY          TIME CMD
stephane 11954 31685  0 09:57 pts/8    00:00:00 httpd.pl

Итак, неизвестно, появится ли httpd.pl файл называется так или как-то еще. perl все еще мог быть запущен с кодом, переданным как -e , или из другого файла, или из стандартного ввода ...

Если код perl был загружен из файла с именем httpd.pl (или любой другой файл по этому поводу), вы, вероятно, не могли бы сказать ни того, ни другого, потому что perl обычно закрывает файл после прочтения его содержимого, поэтому он не отображается в вывод lsof -p PID .

Если сценарий действительно был передан интерпретатору perl и если код perl впоследствии не изменяет имя процесса или аргументы, вы можете получить подсказку, посмотрев на его аргументы командной строки с помощью ps -fp PID .

Тогда вы увидите путь к файлу, переданный в качестве аргумента. Это может быть относительный путь, и в этом случае вы можете посмотреть запись cwd в lsof , которая поможет, если сценарий не изменит текущий рабочий каталог.

Если сценарий был запущен оболочкой, вы также можете найти путь (опять же, возможно, относительный) в переменной среды _ ( grep -z '^ _ =' / proc / PID / Environment в Linux).

В любом случае, сценарий вполне мог удалить себя первым делом при запуске.

Если вы хотите увидеть код этого httpd.pl , лучше всего будет выгрузить содержимое памяти этого процесса (например, с gcore , поставляется с gdb или просматривает / proc / PID / {maps, mem} в Linux). И ищи там код.

Например, при поиске #! в записях с разделителями NUL:

perl -e '$p=shift;open MAPS, "/proc/$p/maps";
  open MEM, "/proc/$p/mem" or die "open mem: $!";
  for $m (grep !m{/|\[v}, <MAPS>){
    ($a,$b) = map hex, $m =~ /[\da-f]+/g;
    seek MEM, $a, 0 or die "seek: $!";
    read MEM, $c, $b - $a or die "read: $!";
    print $c
  }' PID | grep -z '#!'

YYMV, хотя необработанный исходный код может там больше не присутствовать. Затем вам нужно будет найти предварительно скомпилированный код и расшифровать его.

Эти вопросы и ответы по stackoverflow помогут вам в этом.

Прежде всего, вам не нужен конвейер через grep:lsof -i:$PORTвыбирает список файлов, любой из интернет-адресов которых использует заданный номер $PORT (или имя службы ), поэтому

lsof -i:smtp

будет достаточно в вашем примере.

Если вместо этого вы уже знаете имя команды, lsof -c $COMMANDвыбирает список файлов для процессов, выполняющих команду с именем $COMMAND, например:

lsof -c httpd.pl

Третье замечание :Если вы знаете PID процесса, вы можете получить полный путь к его команде с помощью

ps -p $PID -o command

, где $PID— номер PID.

Поэтому, если вам нужно узнать полный путь к команде из результата lsof, вы можете использовать:

ps -p $(lsof -i:$PORT |awk 'NR>1 {print $2}' |sort -n |uniq) -o comm

или

ps -p $(lsof -c $COMMAND |awk 'NR>1 {print $2}' |sort -n |uniq) -o comm

Уведомление 1 :awk,sort, uniqнеобходимы для пропуска строки заголовка из вывода и для агрегирования листинга по номеру PID.

Уведомление 2 :Если вы используете порт назначения $PORT, который используется несколькими процессами (, например, https ), вам потребуется анализировать каждую строку отдельно:

for PID in $(lsof -i:$PORT |awk 'NR>1 {print $2}' |sort -n |uniq); do
  ps -p $PID -o comm
done