2009-05-18 14 views
10

Ho un sacco di flussi e applicazioni di elaborazione dati che occasionalmente ho bisogno di spiare, nel senso che ho bisogno di sapere quali file leggono. Questo è principalmente utile per i test di packaging, ma può anche essere utile durante il debug.Come posso rilevare gli accessi ai file in Linux?

Esiste un modo per eseguire gli eseguibili in modo tale da produrre un elenco di questo tipo?

ho due pensieri su questo:

  1. c'è un comando che posso invocare e che comando richiama le mie applicazioni. Qualcosa sulla falsariga di GDB. Chiamo GDB, gli do un percorso per l'eseguibile e alcuni argomenti e GDB lo chiama per me. Forse c'è qualcosa di simile a dirmi come vengono utilizzate le risorse di sistema.
  2. Forse la soluzione più interessante (ma non necessaria).
    1. creare libreria chiamata libc.so che implementa fopen (e alcuni altri)
    2. cambiamento LD_LIBRARY_PATH per puntare alla nuova libreria
    3. fare una copia del reale libc.so e rinominare fopen (nepof, forse) in un editor
    4. la mia libreria carica la copia e chiama la funzione rinominata secondo necessità per fornire funzionalità fopen.
    5. chiama l'app che quindi chiama il mio proxy fopen.

Alternativa # 1 sarebbe certamente il preferire uno, ma i commenti su come fare # 2 più facilmente sono i benvenuti.

+0

vedere anche http://stackoverflow.com/q/2972765/119790 –

risposta

13

Una possibilità è quella di utilizzare strace:

strace -o logfile -eopen yourapp 

Questo registrerà tutti gli eventi su file aperto, ma lo farà imporre una penalizzazione delle prestazioni che potrebbe essere significativa. Tuttavia ha il vantaggio di essere facile da usare.

Un'altra opzione è utilizzare LD_PRELOAD. Questo corrisponde alla tua opzione # 2. L'idea di base è quella di fare qualcosa di simile:

#define _GNU_SOURCE 
#include <stdio.h> 
#include <dlfcn.h> 

int open(const char *fn, int flags) { 
    static int (*real_open)(const char *fn, int flags); 

    if (!real_open) { 
     real_open = dlsym(RTLD_NEXT, "open"); 
    } 

    fprintf(stderr, "opened file '%s'\n", fn); 
    return real_open(fn, flags); 
} 

Poi costruire con:

gcc -fPIC -shared -ldl -o preload-example.so preload-example.c 

ed eseguire il programma, ad esempio con:

$ LD_PRELOAD=$PWD/preload-example.so cat /dev/null 
opened file '/dev/null' 

Questo ha molto meno overhead.

Si noti, tuttavia, che ci sono altri punti di ingresso per l'apertura dei file - per esempio, fopen(), openat(), o uno dei tanti punti di ingresso di compatibilità legacy:

00000000000747d0 g DF .text  000000000000071c GLIBC_2.2.5 _IO_file_fopen 
0000000000068850 g DF .text  000000000000000a GLIBC_2.2.5 fopen 
000000000006fe60 g DF .text  00000000000000e2 GLIBC_2.4 open_wmemstream 
00000000001209c0 w DF .text  00000000000000ec GLIBC_2.2.5 posix_openpt 
0000000000069e50 g DF .text  00000000000003fb GLIBC_2.2.5 _IO_proc_open 
00000000000dcf70 g DF .text  0000000000000021 GLIBC_2.7 __open64_2 
0000000000068a10 g DF .text  00000000000000f5 GLIBC_2.2.5 fopencookie 
000000000006a250 g DF .text  000000000000009b GLIBC_2.2.5 popen 
00000000000d7b10 w DF .text  0000000000000080 GLIBC_2.2.5 __open64 
0000000000068850 g DF .text  000000000000000a GLIBC_2.2.5 _IO_fopen 
00000000000d7e70 w DF .text  0000000000000020 GLIBC_2.7 __openat64_2 
00000000000e1ef0 g DF .text  000000000000005b GLIBC_2.2.5 openlog 
00000000000d7b10 w DF .text  0000000000000080 GLIBC_2.2.5 open64 
0000000000370c10 g DO .bss  0000000000000008 GLIBC_PRIVATE _dl_open_hook 
0000000000031680 g DF .text  0000000000000240 GLIBC_2.2.5 catopen 
000000000006a250 g DF .text  000000000000009b GLIBC_2.2.5 _IO_popen 
0000000000071af0 g DF .text  000000000000026a GLIBC_2.2.5 freopen64 
00000000000723a0 g DF .text  0000000000000183 GLIBC_2.2.5 fmemopen 
00000000000a44f0 w DF .text  0000000000000088 GLIBC_2.4 fdopendir 
00000000000d7e70 g DF .text  0000000000000020 GLIBC_2.7 __openat_2 
00000000000a3d00 w DF .text  0000000000000095 GLIBC_2.2.5 opendir 
00000000000dcf40 g DF .text  0000000000000021 GLIBC_2.7 __open_2 
00000000000d7b10 w DF .text  0000000000000080 GLIBC_2.2.5 __open 
0000000000074370 g DF .text  00000000000000d7 GLIBC_2.2.5 _IO_file_open 
0000000000070b40 g DF .text  00000000000000d2 GLIBC_2.2.5 open_memstream 
0000000000070450 g DF .text  0000000000000272 GLIBC_2.2.5 freopen 
00000000000318c0 g DF .text  00000000000008c4 GLIBC_PRIVATE __open_catalog 
00000000000d7b10 w DF .text  0000000000000080 GLIBC_2.2.5 open 
0000000000067e80 g DF .text  0000000000000332 GLIBC_2.2.5 fdopen 
000000000001e9b0 g DF .text  00000000000003f5 GLIBC_2.2.5 iconv_open 
00000000000daca0 g DF .text  000000000000067b GLIBC_2.2.5 fts_open 
00000000000d7d60 w DF .text  0000000000000109 GLIBC_2.4 openat 
0000000000068850 w DF .text  000000000000000a GLIBC_2.2.5 fopen64 
00000000000d7d60 w DF .text  0000000000000109 GLIBC_2.4 openat64 
00000000000d6490 g DF .text  00000000000000b6 GLIBC_2.2.5 posix_spawn_file_actions_addopen 
0000000000121b80 g DF .text  000000000000008a GLIBC_PRIVATE __libc_dlopen_mode 
0000000000067e80 g DF .text  0000000000000332 GLIBC_2.2.5 _IO_fdopen 

Potrebbe essere necessario collegare tutti questi per completezza - per lo meno, quelli non prefissati con _ dovrebbero essere agganciati.In particolare, assicuratevi di agganciare fopen separatamente, poiché la chiamata interna a libc da fopen() a open() non è agganciata da una libreria LD_PRELOAD.

Un avvertimento simile vale per strace: c'è anche il syscall "openat" e, a seconda dell'architettura, potrebbero esserci anche altre syscalls legacy. Ma non così tanti come con gli hook LD_PRELOAD, quindi se non ti interessa il colpo di performance, potrebbe essere un'opzione più semplice.

4
man strace 

esempio (assumere 2343 è l'ID del processo):

# logging part 
strace -p 2343 -ff -o strace_log.txt 

# displaying part 
grep ^open strace_log.txt 
2

Quello che uso è qualcosa di simile:

strace -o file.txt ./command 

È possibile quindi

cat file.txt | grep open 

per ottenere un elenco di tutti i file che il programma aperto.

Problemi correlati