spieglt/whatfilesЛогировать, к каким файлам обращается любой процесс Linux.
Whatfiles — это утилита для Linux, которая регистрирует, какие файлы другая программа читает, записывает, создаёт или удаляет в вашей системе. Она также отслеживает все новые процессы и потоки, создаваемые целевым процессом, и записывает, успешно ли завершилась каждая операция.
Меня давно раздражало отсутствие простой утилиты, позволяющей увидеть, к каким файлам обращается процесс от main() до завершения. Независимо от того, доверяете ли вы поставщику программного обеспечения или беспокоитесь о вредоносном ПО, важно знать, что программа или установщик делает с вашей системой. lsof показывает лишь момент времени, а strace громоздок и несколько сложен.
mode: exec, file: /usr/bin/cp, syscall: execve(), PID: 17004, process: sh, result: 0
mode: read, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: -1 (No such file or directory)
mode: read, file: /etc/hostname, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 3
mode: write+create, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 4
mode: chmod, file: /tmp/demo/copy.txt, syscall: fchmodat(), PID: 17005, process: /usr/bin/chmod, result: 0
mode: rename, file: /tmp/demo/copy.txt, to: /tmp/demo/renamed.txt, syscall: renameat2(), PID: 17006, process: /usr/bin/mv, result: 0
mode: read, file: /tmp/demo/missing.txt, syscall: openat(), PID: 17007, process: /usr/bin/cat, result: -1 (No such file or directory)
mode: delete, file: /tmp/demo/renamed.txt, syscall: unlinkat(), PID: 17008, process: /usr/bin/rm, result: 0
Каждая строка сообщает, что было сделано с файлом, сам файл, какой системный вызов это выполнил, какой процесс и поток, и что вернуло ядро. Пути всегда абсолютные: относительные пути разрешаются относительно рабочего каталога процесса или относительно каталога, переданного в системный вызов *at(). result — это возвращаемое значение системного вызова, поэтому неудачный и успешный доступ можно различить.
Помимо открытия, создания и удаления, whatfiles сообщает о rename, link, symlink, mkdir, rmdir, truncate, chmod, chown и exec программы. В SYSCALLS.md описано, что пока не регистрируется и почему каждое добавление было бы полезным.
базовое использование, запускает ls и записывает вывод в файл журнала в текущем каталоге:
$ whatfiles ls -lah ~/Documents
указать расположение выходного файла с помощью -o:
$ whatfiles -o MyLogFile cd ..
включить отладочный вывод, печатать в stdout вместо файла журнала:
$ whatfiles -d -s apt install zoom
подключиться к уже запущенному процессу (требуются права root):
$ sudo whatfiles -p 1234
завершить отслеживаемую программу, если сам whatfiles будет убит, вместо того чтобы позволить ей продолжить работу без трассировки:
$ whatfiles -k ./installer.sh
Нажмите Ctrl-C в любой момент: whatfiles отсоединяется от всего, что отслеживает, оставляет эти процессы работающими и завершает запись журнала.
Готовые к использованию бинарные файлы находятся на странице releases! Кто-то также любезно добавил его в репозиторий Arch, а letompouce настроил конвейер GitLab.
gcc и make):$ cd whatfiles
$ make
$ sudo make install
Поддерживаются архитектуры x86, x86_64, ARM32 и ARM64. make install учитывает PREFIX и DESTDIR.
Требуется Linux 3.4 или новее. На Linux 5.3 и новее whatfiles напрямую запрашивает у ядра информацию о каждой остановке системного вызова, что позволяет корректно декодировать 32-битные системные вызовы на 64-битной машине; на более старых ядрах он возвращается к чтению регистров.
Кросс-компиляция с помощью NDK, затем отправьте бинарный файл на устройство:
$ make android NDK=~/Android/Sdk/ndk/<version>
$ adb push bin/whatfiles-android /data/local/tmp/whatfiles
$ adb shell chmod 755 /data/local/tmp/whatfiles
$ adb shell /data/local/tmp/whatfiles -o /data/local/tmp/ls.log ls /sdcard
ANDROID_ABI выбирает arm64 (по умолчанию) либо arm32, x86_64 или x86. ANDROID_API задаёт
минимальный уровень API и по умолчанию равен 21.
На устройстве есть несколько отличий:
/data/local/tmp. /sdcard смонтирован без разрешения на выполнение.adb shell недоступен для записи, поэтому передайте -o с путём внутри
/data/local/tmp или -s для записи в stdout.adb root на сборке userdebug. На эмуляторе Android 14 это работало при включённом SELinux enforcing;
политика производственного устройства всё ещё может отказать.make test-android NDK=~/Android/Sdk/ndk/<version> собирает whatfiles и тестовые программы для
подключённого устройства, запускает проверки там и удаляет то, что было отправлено.make test собирает программы в tests/ и запускает их под whatfiles для проверки его поведения, включая доставку сигналов, охват потоков и дочерних процессов, а также обработку прерываний.
Разве это не просто повторная реализация strace -fe trace=creat,open,openat,unlink,unlinkat ./program?
Да. Хотя она стремится быть проще и удобнее для пользователя.
Есть ли версии для Mac и Windows?
Нет. Трассировка системных вызовов на Mac требует task_for_pid(), что требует подписи кода, которую я не могу заставить работать, и в любом случае у меня нет интереса платить Apple $100 в год за написание свободного программного обеспечения. dtruss на Mac можно использовать для отслеживания одного процесса и его дочерних процессов, хотя флаг -t, похоже, принимает только один системный вызов для фильтрации. fs_usage делает нечто подобное, хотя я не уверен, отслеживает ли он дочерние процессы/потоки. Process Monitor для Windows довольно хорош.
Программы, которые передают управление своей копии. Особенно браузеры: если экземпляр уже
запущен, тот, который вы запускаете, передаёт ваш запрос ему и завершается, поэтому whatfiles нечего
отслеживать и он останавливается, а запрошенное вами окно появляется из неотслеживаемой копии. Отслеживайте отдельный
экземпляр, например с помощью whatfiles firefox --no-remote --profile ~/ff-trace-profile
и каталога профиля, который ещё не существует, или сначала закройте запущенную копию.
Не является границей безопасности. Программа, которая не хочет, чтобы за ней наблюдали, может определить, что её трассируют, а io_uring выполняет файловые операции без системных вызовов, которые отслеживает whatfiles. Относитесь к журналу как к описанию того, что программа сделала, а не как к доказательству всего, что она могла сделать.
Скорость. Каждый системный вызов дважды останавливает отслеживаемый процесс, поэтому программы с интенсивным использованием системных вызовов работают в несколько раз медленнее обычного. Это та же цена, которую платит strace при отслеживании всех системных вызовов.
Для подключения нужны привилегии. -p обычно требует root или ослабленного /proc/sys/kernel/yama/ptrace_scope. Отказ в подключении оставляет цель работать нормально.
Если whatfiles будет убит напрямую с помощью SIGKILL, программа, которую он отслеживал, продолжит работу без трассировки, если только она не была запущена с -k.
Спасибо за ваш интерес, и, пожалуйста, также ознакомьтесь с Cloaker, Nestur и Flying Carpet!