Lista plików, do których program ma dostęp

time to genialne polecenie, jeśli chcesz dowiedzieć się, ile czasu zajmuje procesor.

Szukam czegoś podobnego, który może wyświetlić listę plików, do których program i jego dzieci mają dostęp. Albo w czasie rzeczywistym, albo jako raport później.

Obecnie używam:

#!/bin/bash

strace -ff -e trace=file "$@" 2>&1 | perl -ne 's/^[^"]+"(([^\\"]|\\[\\"nt])*)".*/$1/ && print'

ale kończy się niepowodzeniem, jeśli polecenie do uruchomienia dotyczy sudo. Nie jest zbyt inteligentny (byłoby miło, gdyby mógł wyświetlać tylko listę istniejących plików, które miały problemy z uprawnieniami lub pogrupować je w odczytywane pliki i zapisywane). straceJest również powolny, więc dobrze by było z szybszym wyborem.

Zrezygnowałem i kodowałem własne narzędzie. Cytując z jego dokumentów:

SYNOPSIS
    tracefile [-adefnu] command
    tracefile [-adefnu] -p pid

OPTIONS
    -a        List all files
    -d        List only dirs
    -e        List only existing files
    -f        List only files
    -n        List only non-existing files
    -p pid    Trace process id
    -u        List only files once

Wysyła tylko pliki, więc nie musisz zajmować się danymi wyjściowymi strace.

https://gitlab.com/ole.tange/tangetools/tree/master/tracefile

Możesz śledzić wywołania systemowe strace, ale rzeczywiście istnieje nieunikniona kara za prędkość. Musisz uruchomić stracejako root, jeśli polecenie działa z podwyższonymi uprawnieniami:

sudo strace -f -o foo.trace su user -c 'mycommand'

Inna metoda to prawdopodobnie szybciej jest przekręceniem biblioteki, który owija się wokół funkcji dostępu do systemu plików: LD_PRELOAD=/path/to/libmywrapper.so mycommand. LD_PRELOADZmienna środowiskowa nie zostanie przekazana do programów wywołany z podwyższonymi uprawnieniami. Musiałbyś napisać kod tej biblioteki opakowań ( oto przykład z „Budowania pośredników bibliotek dla zabawy i zysku” ); Nie wiem, czy w sieci dostępny jest kod wielokrotnego użytku.

Jeśli monitorujesz pliki w określonej hierarchii katalogów, możesz utworzyć widok systemu plików za pomocą LoggedFS, tak aby wszystkie dostępy przez ten widok były rejestrowane.

loggedfs -c my-loggedfs.xml /logged-view
mycommand /logged-view/somedir

Aby skonfigurować LoggedFS, zacznij od przykładowej konfiguracji dostarczonej z programem i przeczytaj składnię pliku konfiguracyjnego LoggedFS .

Inną możliwością jest podsystem kontroli systemu Linux . Upewnij się, że auditddemon jest uruchomiony, a następnie skonfiguruj, z czym chcesz się zalogować auditctl. Każda zarejestrowana operacja jest rejestrowana w /var/log/audit/audit.log(w typowych dystrybucjach). Aby rozpocząć oglądanie określonego pliku:

auditctl -a exit,always -w /path/to/file

Jeśli umieścisz zegarek w katalogu, pliki w nim i jego podkatalogi będą również rekurencyjnie oglądane. Uważaj, aby nie oglądać katalogu zawierającego dzienniki kontroli. Możesz ograniczyć rejestrowanie do niektórych procesów, zobacz auditctlstronę podręcznika dla dostępnych filtrów. Musisz być rootem, aby korzystać z systemu kontroli.

Myślę, że chcesz lsof (prawdopodobnie dołączony do grepa w programie i to dzieci). Powie ci każdy plik, który jest aktualnie dostępny w systemie plików. Aby uzyskać informacje o tym, do których plików można uzyskać dostęp przez proces ( stąd ):

lsof -n -p `pidof your_app`

Próbowałem tego tracefile. Dla mnie dało to znacznie mniej wyników niż moje własne strace ... | sed ... | sort -u. Dodałem nawet -s256do strace(1)wiersza poleceń, ale niewiele to pomogło ...

Potem spróbowałem loggedfs. Po pierwsze nie powiodło się, ponieważ nie miałem dostępu do odczytu / zapisu do katalogu, w którym próbowałem się zalogować. Po tymczasowym zrobieniu chmod 755 dostałem kilka hitów ...

Ale dla mnie najlepsze wydaje się wykonanie następujących czynności:

inotifywait -m -r -e OPEN /path/to/traced/directory

A następnie przetwarzaj dane wyjściowe po przetworzeniu interesującego Cię procesu.

Nie łapie to dostępu do procesu procesowego dostępu do katalogu śledzonego ani nie wie, czy jakiś inny proces uzyskał dostęp do tego samego drzewa katalogów, ale w wielu przypadkach jest to wystarczające narzędzie do wykonania zadania.

EDYCJA: inotifywait nie przechwytuje dostępu do dowiązań symbolicznych (tylko cele po rozwiązaniu dowiązań symbolicznych). Uderzyło mnie to, gdy zarchiwizowałem biblioteki, do których program ma dostęp w przyszłości. Użyłem dodatkowej globalnej hackery w Perlu, aby wybrać dowiązania symboliczne wzdłuż powiadomionych bibliotek, aby wykonać zadanie w tym konkretnym przypadku.

EDYCJA 2: przynajmniej podczas powiadamiania samych plików i dowiązań symbolicznych z wiersza poleceń inotifywait (np. inotifywait -m file symlinkLub inotifywait symlink file) pokaże dostęp do tego, który z nich jest pierwszy w wierszu poleceń (niezależnie od tego, który filez nich symlinkjest dostępny). inotifywait nie obsługuje IN_DONT_FOLLOW - co, gdy próbowałem programowo, pozwala tylko zobaczyć dostęp file(który może, ale nie musi, być tym, czego się spodziewa ...) niezależnie od kolejności w wierszu poleceń

Chociaż może nie dać ci wystarczającej kontroli (jeszcze?) Napisałem program, który przynajmniej częściowo spełnia twoje potrzeby, używając fanotify i nieudostępniania jądra linux-to do monitorowania tylko plików zmodyfikowanych (lub odczytanych) przez określony proces i jego potomków . W porównaniu do strace jest dość szybki (;

Można go znaleźć na https://github.com/tycho-kirchner/shournal

Przykład na powłoce:

$ shournal -e sh -c 'echo hi > foo1; echo hi2 > foo2'
$ shournal -q --history 1
  # ...
  Written file(s):                                                                                                                                                                              
 /tmp/foo1 (3 bytes) Hash: 15349503233279147316                                                                                                                                             
 /tmp/foo2 (4 bytes) Hash: 2770363686119514911