Снова задачка, связанная с анализом какого-либо приложения, когда нам хочется оперативно посмотреть, как работает программа, какие файлы она  читает или порты открывает. На  основе таких данных мы найдем кри тичные файлы, возможно какие-то некорректные права в  ОС. Это важное подспорье для понимания, как что-то работает. И если с Windows все сво дится к наборчику Sysinternals Tools c его тулзами ProcMon, FileMon, RegMon, с  которыми легко можно решить поставленные зада чи, то как обстоят дела с nix’ами, точнее даже с Linux-системами? Как это ни странно — вполне хорошо, и даже лучше, чем под винду. Чаще всего мож но справиться с основными задачами даже без стороннего ПО (и как обыч но для nix’ов — различными путями). Итак, для начала нам поможет команда lsof, которая по умолчанию ото бражает все открытые файлы в  ОС  и  процессы, которые «стоят» за  этим. Но так как мы анализируем конкретное ПО, то мы можем ограничить вывод только по нему, а точнее по его PID’у: 

Тулзень хороша еще и тем, что показывает нам перечень подгруженных
библиотек, а также портов, открытых данным процессом (помним, что в nix-системах каждая сущность является файлом, поэтому мы ее тут тоже видим). Иногда бывает полезно сначала найти, а что же за процесс сидит на конкретном порту:

Кроме того, можно «фильтровать» по имени пользователя:
 
Минус для нас в том, что если файл (с конфигом, например) был открыт, а на момент запуска lsof уже закрыт процессом, то мы его не увидим в списке. Воспользуемся тогда другой тулзой, от которой данные моменты не укроются, — strace (или одним из ее аналогов). Она фактически мониторит системные вызовы для какого-то приложения. 

Здесь
• -f указывает, что необходимо трейсить и child’ы (порожденные процессы);
• -e trace=open — что нас интересует только открытие файлов;
• -p116 — PID процесса, к которому приаттачится strace;
• -o ~/log — куда сохранять логи (иначе — на стандартный вывод).
Если хотим оттрейсить с  самого запуска, то  вместо -p команду с  аргументами указываем в конце после параметров.
О’кей, с  этой частью разобрались. Если есть процесс, то  понять, куда и  когда он  ползает, мы сможем. А  как  насчет другой части задачки, когда у нас есть некий файл и надо узнать, кто и когда им пользуется? Strac здесь уже не помощник, так как он не может мониторить системные вызовы от всех процессов.
Рассмотрим пару.
Первый — демон Linux auditd. Похож на strace, также позволяет просматривать системные вызовы, но  на  уровне всей ОС. Правда, в  работе «по-толще» и требует установки (хотя sudo apt-get install auditd и 600 Кб места...). Для работы с auditd нам потребуется две команды. Сначала устанавливаем аудит события, используя auditctl:
sudo auditctl -w /etc/passwd -k passwd_mon -p rw
• -w /etc/passwd — путь до файла, который мониторим;
• -k passwd_mon — ключ, по которому можно будет найти события, относящиеся к данному правилу;
• -p rw — контролировать доступ на чтение и запись.
Далее можно посмотреть события с помощью команды ausearch:

• -k passwd_mon — как раз ключ, который мы указали ранее.
Две дополнительные команды. Удаление правила (аналогично созданию, только с заглавной W):
sudo auditctl -W /etc/passwd -k passwd_mon -p rw
Список правил:

Система аудита событий достаточно мощная. Логи содержат много информации. Так что можно читать мануалы и радоваться жизни. С ней главное - не погрязнуть в обилии полученных данных. Если же тебе нравится больше GUI и минимум изменений в ОС, то можно взглянуть на тулзу glsof. Она написана на Java, систематически запускает lsof, парсит его вывод и оставляет только интересующую нас информацию. Кирпично, но работает. С первой задачкой также справится (считай это GUI для lsof). Минус может быть в том, что если за промежуток между запусками lsof процесс успеет обратиться к файлу и закончить с ним работу, то мы этого в логе не увидим.

 Еще момент. Одним из первых решений было использование подсистемы inotify, которая дает возможность гибко мониторить доступ к  файлам и  папкам на  уровне файловой системы. Для  доступа к  ней использовал iWatch. Все заработало быстро и четко, кроме одного важного момента — через inotify нет возможности узнать, какой процесс производит изменения.
Спасибо за внимание и успешных познаний нового!