Назад к обновлениям
New releaseSep 18, 2026

whatfiles v2.0

Логировать, к каким файлам обращается любой процесс Linux.

Поделиться

whatfiles

build and test

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-битной машине; на более старых ядрах он возвращается к чтению регистров.

Android

Кросс-компиляция с помощью 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.
  • Запуск команды под whatfiles работает от имени обычного пользователя оболочки, как и подключение к процессу, запущенному этим пользователем. Подключение к чему-либо другому, например к приложению, требует root, поэтому adb root на сборке userdebug. На эмуляторе Android 14 это работало при включённом SELinux enforcing; политика производственного устройства всё ещё может отказать.
  • make test-android NDK=~/Android/Sdk/ndk/<version> собирает whatfiles и тестовые программы для подключённого устройства, запускает проверки там и удаляет то, что было отправлено.
  • 32-битное приложение, отслеживаемое из сборки arm64, читается с 32-битными номерами системных вызовов и регистрами аргументов, а не принимается за 64-битное. Этот путь не был проверен на реальном оборудовании: используемый здесь для тестирования эмулятор не имеет 32-битного ABI.

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.

Планируемые функции:

  • В настоящее время нет, открыт для запросов и PR.

Спасибо за ваш интерес, и, пожалуйста, также ознакомьтесь с Cloaker, Nestur и Flying Carpet!

Категории