Cada línea indica qué se hizo con el archivo, el archivo en sí, qué llamada al sistema lo hizo, qué proceso e hilo, y qué devolvió el kernel. Las rutas son siempre absolutas: las rutas relativas se resuelven contra el directorio de trabajo del proceso, o contra el directorio que pasó a una llamada al sistema *at(). result es el valor de retorno de la llamada al sistema, por lo que se puede distinguir entre acceso fallido y exitoso.

Además de abrir, crear y eliminar, whatfiles informa sobre rename, link, symlink, mkdir, rmdir, truncate, chmod, chown y exec de un programa. SYSCALLS.md cubre lo que aún no se informa y por qué cada adición valdría la pena.

Uso:

• uso básico, lanza ls y escribe la salida en un archivo de registro en el directorio actual:

  $ whatfiles ls -lah ~/Documents

• especifica la ubicación del archivo de salida con -o:

  $ whatfiles -o MyLogFile cd ..

• incluye salida de depuración, imprime en stdout en lugar del archivo de registro:

  $ whatfiles -d -s apt install zoom

• adjúntate a un proceso en ejecución (requiere privilegios de root):

  $ sudo whatfiles -p 1234

• mata el programa rastreado si whatfiles mismo es terminado, en lugar de dejarlo continuar sin rastrear:

  $ whatfiles -k ./installer.sh

Pulsa Ctrl-C en cualquier momento: whatfiles se desadjunta de todo lo que está rastreando, deja esos procesos en ejecución y termina de escribir el registro.

Distribución

¡Hay binarios listos para usar en la página de releases! Alguien también lo añadió amablemente al repositorio de Arch, y letompouce configuró también un pipeline de GitLab.

Compilación (requiere gcc y make):

Compatible con las arquitecturas x86, x86_64, ARM32 y ARM64. make install respeta PREFIX y DESTDIR.

Se requiere Linux 3.4 o superior. En Linux 5.3 y superior, whatfiles pregunta directamente al kernel sobre cada parada de llamada al sistema, lo que hace que las llamadas al sistema de 32 bits en una máquina de 64 bits se decodifiquen correctamente; en kernels más antiguos recurre a la lectura de registros.

Android

Compila de forma cruzada con el NDK, luego envía el binario al dispositivo:

ANDROID_ABI selecciona arm64, el valor predeterminado, o arm32, x86_64 o x86. ANDROID_API establece el nivel de API mínimo y por defecto es 21.

Algunas cosas difieren en un dispositivo:

• Coloca el binario en /data/local/tmp. /sdcard está montado sin permiso de ejecución.
• El directorio de trabajo en adb shell no es escribible, así que pasa -o con una ruta bajo /data/local/tmp, o -s para escribir en stdout.
• Ejecutar un comando bajo whatfiles funciona como el usuario de shell ordinario, y también adjuntarse a un proceso que ese usuario inició. Adjuntarse a cualquier otra cosa, una app por ejemplo, necesita root, así que adb root en una compilación userdebug. En un emulador de Android 14 eso funcionó con SELinux en modo enforcing; la política de un dispositivo de producción aún podría rechazarlo.
• make test-android NDK=~/Android/Sdk/ndk/<version> compila whatfiles y los programas de prueba para el dispositivo conectado, ejecuta las comprobaciones allí y elimina lo que envió.
• Una app de 32 bits rastreada desde una compilación arm64 se lee con los números de llamada al sistema de 32 bits y los registros de argumentos en lugar de tomarla por una de 64 bits. Esa ruta no se ha ejercitado en hardware real: el emulador usado para las pruebas aquí no tiene ABI de 32 bits.

make test compila los programas en tests/ y los ejecuta bajo whatfiles para comprobar su comportamiento, incluyendo la entrega de señales, la cobertura de hilos y procesos hijos, y el manejo de interrupciones.

Preguntas que podrían plantearse en algún momento:

• ¿No es esto solo una reimplementación de strace -fe trace=creat,open,openat,unlink,unlinkat ./program?

  Sí. Aunque pretende ser más simple y fácil de usar.

• ¿Hay versiones para Mac y Windows?

  No. Rastrear llamadas al sistema en Mac requiere task_for_pid(), que requiere firma de código, que no consigo hacer funcionar, y de todos modos no tengo interés en pagarle a Apple 100 $/año para escribir software libre. dtruss en Mac puede usarse para seguir un solo proceso y sus hijos, aunque el flag -t parece aceptar solo una única llamada al sistema para filtrar. fs_usage hace algo similar aunque no estoy seguro de si sigue procesos/hilos hijos. Process Monitor para Windows es bastante bueno.

Limitaciones:

• Programas que delegan en una copia de sí mismos. Los navegadores especialmente: si ya hay una instancia en ejecución, la que lanzas le pasa tu solicitud y sale, así que whatfiles no tiene nada que rastrear y se detiene, mientras que la ventana que pediste proviene de la copia no rastreada. Rastrea una instancia separada en su lugar, con algo como whatfiles firefox --no-remote --profile ~/ff-trace-profile y un directorio de perfil que aún no exista, o cierra primero la copia en ejecución.

• No es una frontera de seguridad. Un programa que no quiere ser vigilado puede darse cuenta de que está siendo rastreado, y io_uring realiza operaciones de archivos sin las llamadas al sistema que whatfiles vigila. Trata el registro como una descripción de lo que hizo un programa, no como prueba de todo lo que pudo haber hecho.

• Velocidad. Cada llamada al sistema detiene el proceso rastreado dos veces, así que los programas con muchas llamadas al sistema se ejecutan varias veces más lento de lo habitual. Este es el mismo coste que paga strace al seguir todas las llamadas al sistema.

• Adjuntarse necesita privilegios. -p generalmente requiere root, o un /proc/sys/kernel/yama/ptrace_scope relajado. Un intento de adjuntarse rechazado deja el objetivo ejecutándose con normalidad.

• Si whatfiles es terminado de forma abrupta con SIGKILL, el programa que estaba rastreando sigue ejecutándose, sin rastrear, a menos que se haya iniciado con -k.

Funciones planificadas:

• Ninguna actualmente, abierto a peticiones y PRs.

¡Gracias por tu interés, y por favor echa también un vistazo a Cloaker, Nestur y Flying Carpet!