¿Es posible averiguar qué programa o script creó un archivo determinado?


35

De repente aparecieron tres archivos en mi directorio de inicio, llamados "client_state.xml", "lockfile" y "time_stats_log". Los dos últimos están vacíos. Me pregunto cómo llegaron allí. No es la primera vez que sucede, pero la última fue hace semanas; Eliminé los archivos y nada se rompió ni se quejó. No he podido pensar en lo que estaba haciendo en el momento informado por stat $filename. ¿Hay alguna manera de saber de dónde vienen?

Alternativamente, ¿hay alguna forma de monitorear el directorio de inicio (pero no los subdirectorios) para la creación de archivos?


Como estoy seguro de que alguien lo mencionará, no tengo inotify.
Lobo

Respuestas:


18

No creo que haya una manera de determinar qué programa creó un archivo.

Para su pregunta alternativa: sin embargo, puede ver cómo se recrea el archivo con inotify. inotifywaites una interfaz de línea de comandos para el inotifysubsistema; puede decirle que busque createeventos en su directorio de inicio:

$ (sleep 5; touch ~/making-a-test-file) &
[1] 22526

$ inotifywait -e create ~/
Setting up watches.
Watches established.
/home/mmrozek/ CREATE making-a-test-file

Probablemente quiera ejecutarlo con -m(monitor), que le dice que no salga después de ver el primer evento


¿Cómo consigo inotify? No está instalado (kernel 2.6.34) y no hay /dev/inotify.
Wolf

1
@Wolf ¿Qué distribución? Si construye su propio núcleo, es CONFIG_INOTIFY_USER( Filesystems-> Inotify support for userspace). inotifywaitprobablemente esté en un paquete llamado algo así comoinotify-tools
Michael Mrozek

@ Michael, es openSUSE 11.3. Nunca he construido un núcleo; solo he estado usando Linux durante aproximadamente 5 meses y es un concepto un poco desalentador. Pero buscaré un tutorial o algo así.
Wolf

@Wolf Bueno, la respuesta de Dogbane podría ser más fácil si el núcleo que tienes no viene con él
Michael Mrozek

2
@Michael En realidad, después de un poco más de búsqueda e investigación, agregué un repositorio de la comunidad que, al parecer, contiene el inotify-toolspaquete, así que ahora tengo inotifywait(y inotifywatch). Lo probé y parece funcionar.
Lobo

22

Puede ver todo lo que sucede en un sistema de archivos accediendo a él a través de LoggedFS . Este es un sistema de archivos apilado que registra cada acceso en un árbol de directorios.

loggedfs -l /var/tmp/$USER-home-fs.log ~

Sin embargo, registrar todo el directorio de inicio puede ralentizar su sistema. Al menos querrás escribir un archivo de configuración con filtros estrictos.

Si tiene acceso de root, en Linux, puede usar el subsistema de auditoría para registrar una gran cantidad de cosas, incluidos los accesos al sistema de archivos. Asegúrese de que el auditddemonio esté iniciado, luego configure con qué desea iniciar sesión auditctl. Cada operación registrada se registra en /var/log/audit/audit.log(en distribuciones típicas). Para comenzar a mirar un archivo en particular:

auditctl -w /path/to/file

o en la forma larga

auditctl -a exit,always -F path=/path/to/file

Si coloca un reloj en un directorio (con -wo -F dir=), los archivos en él y sus subdirectorios también se verán de forma recursiva.


BSD también lo admite a través de Auditoría de eventos de seguridad. freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
Shawn J. Goff

4

Es posible que desee echar un vistazo auditd, este paquete le permite realizar auditorías de seguridad y obtener mucha información sobre quién cambió qué en el sistema de archivos.


Si tiene un servidor que proporciona acceso a shell para múltiples usuarios y necesita proporcionar cierto nivel de responsabilidad para acciones individuales, puede construir ciertos shells (como bash y tcsh) con el registro del historial de comandos. Escribí una publicación de blog sobre el inicio de sesión en shells en < timkennedy.net/2010/12/07/… >. El registro de shell no es un reemplazo para un sistema de auditoría real, ya que no registrará comandos ejecutados por shells no interactivos (como scripts o programas). Para obtener ese tipo de granularidad, realmente necesita una buena solución de auditoría.
Tim Kennedy el

1
@TimKennedy: tu publicación de blog ya no aparece.
slm

1
Lo siento. el sitio fue pirateado y estuvo fuera de servicio por un tiempo. nueva página está en timkennedy.net/2010/12/logging-shell-commands-to-syslog-on.html
Tim Kennedy

3

Sé que esta es una vieja pregunta, pero sugeriré otro enfoque en caso de que alguien lo encuentre útil. Originalmente publiqué esto como respuesta a una pregunta que fue engañada a esta.

Una opción es usar sysdig: una aplicación de monitoreo de sistema de código abierto. Al usarlo, puede monitorear la actividad en un archivo por nombre. Suponga que desea ver qué proceso estaba creando un archivo llamado /tmp/example.txt:

# sysdig fd.name=/tmp/example.txt
567335 16:18:39.654437223 0 touch (5470) < openat fd=3(<f>/tmp/example.txt) dirfd=-100(AT_FDCWD) name=/tmp/example.txt flags=70(O_NONBLOCK|O_CREAT|O_WRONLY) mode=0666
567336 16:18:39.654438248 0 touch (5470) > dup fd=3(<f>/tmp/example.txt)
567337 16:18:39.654438592 0 touch (5470) < dup res=0(<f>/tmp/example.txt)
567338 16:18:39.654439629 0 touch (5470) > close fd=3(<f>/tmp/example.txt)
567339 16:18:39.654439764 0 touch (5470) < close res=0
567342 16:18:39.654441958 0 touch (5470) > close fd=0(<f>/tmp/example.txt)
567343 16:18:39.654442111 0 touch (5470) < close res=0

De esa salida, puede ver que un proceso llamado touch con pid 5470 abrió el archivo.

Si desea más información, puede ejecutar en "modo de captura" donde se recopila un seguimiento de llamadas del sistema:

# sysdig -w /tmp/dumpfile.scap

Luego espere a que se cree el archivo, luego pare sysdigy ejecute:

# csysdig -r /tmp/dumpfile.scap

Eso te permitirá explorar todo lo que sucedió. Puede presionar <F2>y seleccionar Files, presionar <F4>para buscar el nombre del archivo, luego presionar <F6>para "cavar" (que le mostrará una salida similar al comando anterior). Con eso, puede usar el mismo enfoque para encontrar información sobre el proceso que realmente creó el archivo.

Hay una versión GUI de csysdigllamado sysdig-inspect, si esa es más su taza de té.


o tal vez un bucle ocupado que se ejecuta constantemente tratando de ver si / cuando un proceso está escribiendo en ese archivo ... unix.stackexchange.com/a/13782/8337
rogerdpack

2

No lo tienes, inotifyasí que puedes escribir un script que verifique el archivo en un bucle:

#!/bin/sh

while [ true ]; do                     # Run for as long as nessesary
  if [ -f /path/to/file ]; then        # If fileexists
    echo "Found file"                  # Notify and stop monitoring
    exit 0
  fi
  sleep 5                             # Else wait 5 secs
done

2
Esto no muestra qué programa lo creó
OverCoder
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.