Можно ли сказать, что процессы (с подпроцессами или без них) полностью отражены в их (описательных) файлах?

Я не думаю, что я полностью понимаю, что вы спрашиваете... Пожалуйста, добавьте некоторые объяснения.

Но из того, что я думаю, я понимаю, нет.

Аналогия может быть:

Если я смотрю Лицо А и вижу, с кем они разговаривают, могу ли я определить намерения Лица А?

В этом случае этот ответ довольно темный. Возможно, вы сможете увидеть, что лицо А разговаривает с каким-то важным человеком в правоохранительных органах и, возможно, с некоторыми людьми, связанными с организованной преступностью. Но будет чрезвычайно трудно (невозможно?) Точно определить мотивы личности А. Являются ли они тайным полицейским или преступником с судьей под большим пальцем?

Вы не можете достоверно прочитать что-либо в одно только такое знание.

Если вам удалось получить больше информации, например, о выполняемых операциях ввода-вывода, вы бы смогли лучше понять ситуацию.

Другими словами, если вы посмотрите на каждый файл (представленный дескрипторами файлов в соответствующем порядке, например, 0-X), он скажет вам природу процесса и / или подпроцессов?

Я думаю, что вы несколько озадачены тем, что такое " файловый дескриптор ". Описатель файла идентифицируется простым номером (int) - возвращаемое значение open()... но внутри ядра файловый дескриптор имеет информацию, связанную с ним. Увидеть struct file,

Я полагаю, что ответ был бы да, если действительно, весь процесс действительно сделан только из этих файлов.

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

$ ls -l /proc/self/fd
total 0
lrwx------ 1 attie attie 64 May 20 15:20 0 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 1 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 2 -> /dev/pts/3
lr-x------ 1 attie attie 64 May 20 15:20 3 -> /proc/13103/fd

Как отметил @grawity в комментарии, open() вернет следующий свободный файловый дескриптор, заполняя любые пробелы с нуля. То, что вы видите выше, является снимком файлов, которые в данный момент открыты и будут меняться со временем.

Вы не можете видеть ls двоичный файл в приведенном выше списке или любые его непосредственные зависимости:

$ ldd $(which ls)
        linux-vdso.so.1 =>  (0x00007fff569ef000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007feeb33df000)
        libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007feeb31d7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feeb2e0e000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007feeb2bd0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feeb29cc000)
        /lib64/ld-linux-x86-64.so.2 (0x00007feeb361a000)
        libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007feeb27c6000)

Когда вы пытаетесь " выполнить ls "компоновщик - это на самом деле то, что читает файлы библиотеки для сопоставления и" связывания "полного образа процесса. ls начинает выполняться, эти данные уже находятся в памяти, и файлы больше не "открываются".

Некоторые приложения могут использовать "плагины" или "динамически" загружать дополнительные файлы, которые предоставляют функциональность (см. dlopen()), но это крайний случай, и он далек от типичного поведения - ни один из процессов, запущенных на моем компьютере, не имеет общего объекта (*.so) файл открыт.

В итоге, и все еще в согласии с моим первоначальным ответом, нет.

Нет определенного способа определить поведение процесса, посмотрев, какие файлы у него открыты.

Что касается определения природы подпроцесса, это невозможно - вы можете посмотреть на init и определить полную конфигурацию системы во время выполнения? Нет

Контрпример: напишите две программы, которые спят, скажем, 100 секунд, а затем напишите 1 соотв. 2 к стандарту. Запустите оба из одной оболочки и поместите их в фоновом режиме. Вы не сможете различить их, посмотрев на файловые дескрипторы, которые идентичны для обоих.

Вариант: пусть они откроют один и тот же файл, поэтому он даже не будет работать, если он не ограничен стандартными дескрипторами.

Краткий ответ: да, но очень ограниченным образом.

Фактически, наблюдение за тем, что делает процесс, является одной из основных функций антивируса, так как среди открываемых файлов есть и библиотеки DLL (Windows) или общие библиотеки (Linux). Антивирус, который оценивает поведение процесса, вызовет тревогу, когда процесс откроет слишком много или слишком важные файлы или попытается получить доступ к конфиденциальным папкам. Windows/Linux может запрашивать разрешение пользователя в таких случаях.

Можно обнаружить, что процесс открывает DLL/shared-библиотеку, но для определения того, какие API он вызывает, требуется анализ выполняемых им системных вызовов, которые антивирус может найти, изучив сам исполняемый файл процесса,

Не забывайте, что сам исполняемый файл является одним из открытых файлов, поэтому его анализ может точно определить, какие библиотеки DLL/shared-библиотеки он использует, что может дать очень хорошее представление о том, что он делает.

ОС будет следить за поведением процесса и классифицировать его в классе планирования как связанный с ЦП, связанный с вводом-выводом или смешанный, что повлияет на его приоритет выполнения и разрешенные срезы системных ресурсов.

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

Нет.

Большинство процессов имеют очень похожее поведение дескриптора. Например, почти все демоны записывают свои выходные данные в журналы (файлы), которые часто используются совместно. Например, в моей системе /var/log/journal имеет записи от systemd, gnome-keyring-*, dbus-daemon и много других программ.

Одним из часто используемых шаблонов является перенаправление дескрипторов в / из /dev/{null,zero,urandom,tty*} или закрывая их.

Другой пример - cmp а также diff сделать в основном то же самое, но они имеют дело с различными типами данных.

Есть даже программы в moreutils пакет (который великолепен), который оборачивает некоторые общие шаблоны дескрипторов:

• chronic - запускает команду тихо, если она не работает
• sponge - впитать стандартный ввод и записать в файл (файл открывается после того, как ввод пропитан, так что grep "mom" somefile | sponge somefile оставляет только те строки в файле, которые содержат "мама")
• объединить - объединить наборы строк из двух файлов, используя логические операции (те же дескрипторы, что и diff)

И представьте, как быстро меняются дескрипторы top или же find программы. Вам нужно будет отслеживать их в течение всего времени их выполнения.

Вопрос для домашнего обсуждения: в чем разница в дескрипторах между LibreOffice Writer и GIMP, или лучше, sed а хочешь кричать?