Czy można dowiedzieć się, jaki program lub skrypt utworzył dany plik?


35

W moim katalogu domowym nagle pojawiły się trzy pliki o nazwie „client_state.xml”, „lockfile” i „time_stats_log”. Dwa ostatnie są puste. Zastanawiam się, jak się tam dostali. To nie pierwszy raz, kiedy to się stało, ale ostatni raz minęły tygodnie temu; Usunąłem pliki i nic się nie zepsuło ani nie narzekałem. Nie byłem w stanie myśleć o tym, co robiłem w momencie, kiedy to zgłosił stat $filename. Czy jest jakiś sposób, aby dowiedzieć się, skąd one pochodzą?

Alternatywnie, czy istnieje sposób monitorowania katalogu domowego (ale nie podkatalogów) w celu tworzenia plików?


Ponieważ jestem pewien, że ktoś o tym wspomni, nie mam potwierdzenia.
— Wolf

Odpowiedzi:


18

Nie sądzę, aby można było ustalić, który program utworzył plik.

Na twoje alternatywne pytanie: Możesz jednak uważać na plik do odtworzenia za pomocą inotify. inotifywaitjest interfejsem wiersza poleceń dla inotifypodsystemu; możesz mu powiedzieć, aby szukał createwydarzeń w twoim katalogu domowym:

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

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

Prawdopodobnie chcesz go uruchomić za pomocą -m(monitor), który mówi, aby nie wychodził po zobaczeniu pierwszego zdarzenia


Jak mogę dostać inotify? Nie jest zainstalowany (jądro 2.6.34) i nie ma go /dev/inotify.
— Wolf

1
@Wolf Jaka dystrybucja? Jeśli zbudujesz własne jądro, jest to CONFIG_INOTIFY_USER( Filesystems-> Inotify support for userspace). inotifywaitjest prawdopodobnie w pakiecie o nazwie coś w styluinotify-tools
— Michael Mrozek

@Michael, jest openSUSE 11.3. Nigdy nie budowałem jądra; używam Linuksa tylko około 5 miesięcy i jest to trochę zniechęcająca koncepcja. Ale rozejrzę się za tutorialem lub czymś takim.
— Wolf

@Wolf Cóż, odpowiedź dogbane może być łatwiejsza, jeśli jądro, które masz, nie jest z nią związane
— Michael Mrozek

2
@Michael Właściwie, po trochę więcej polowań i badań, dodałem repozytorium społeczności, które, jak się okazuje, zawiera inotify-toolspakiet, więc teraz mam inotifywait(i inotifywatch). Przetestowałem to i wydaje się, że działa.
— Wolf

22

Możesz oglądać wszystko, co dzieje się w systemie plików, uzyskując do niego dostęp za pośrednictwem LoggedFS . Jest to skumulowany system plików, który rejestruje każdy dostęp w drzewie katalogów.

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

Rejestrowanie całego katalogu domowego może jednak spowolnić system. Przynajmniej będziesz chciał napisać plik konfiguracyjny z surowymi filtrami.

Jeśli masz dostęp do konta root, w systemie Linux możesz użyć podsystemu kontroli do zarejestrowania dużej liczby rzeczy, w tym dostępu do systemu plików. 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 -w /path/to/file

lub w długiej formie

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

Jeśli umieścisz zegarek w katalogu (z -wlub -F dir=), pliki w nim i jego podkatalogi rekurencyjnie będą również oglądane.


BSD obsługuje to również poprzez audyt zdarzeń bezpieczeństwa. freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
— Shawn J. Goff

4

Możesz auditdrzucić okiem , ten pakiet pozwala przeprowadzać audyty bezpieczeństwa i uzyskać wiele informacji o tym, kto zmienił to, co w systemie plików.


jeśli masz serwer, który zapewnia dostęp do powłoki wielu użytkownikom i potrzebujesz pewnego poziomu odpowiedzialności za poszczególne akcje, możesz zbudować określone powłoki (takie jak bash i tcsh) z rejestrowaniem historii poleceń. Napisałem post na blogu o logowaniu się do powłok w < timkennedy.net/2010/12/07/… >. Rejestrowanie powłoki nie zastępuje prawdziwego systemu kontroli, ponieważ nie rejestruje poleceń uruchamianych przez nieinteraktywne powłoki (takie jak skrypty lub programy). Aby uzyskać taki stopień szczegółowości, naprawdę potrzebujesz dobrego rozwiązania kontrolnego.
— Tim Kennedy

1
@TimKennedy - Twój post na blogu już się nie pojawia.
— slm

1
Przepraszam. witryna została zhakowana i przez pewien czas nie działała. nowa strona jest na timkennedy.net/2010/12/logging-shell-commands-to-syslog-on.html
— Tim Kennedy

3

Wiem, że to stare pytanie, ale zasugeruję inne podejście na wypadek, gdyby ktoś uznał je za przydatne. Oryginalnie zamieściłem to jako odpowiedź na pytanie, które zostało skopiowane do tego pytania.

Jedną z opcji jest użycie sysdig: aplikacji do monitorowania systemu typu open source. Za jego pomocą możesz monitorować aktywność w pliku według nazwy. Załóżmy, że chcesz zobaczyć, jaki proces tworzył plik o nazwie /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

Z tego wyniku widać, że proces o nazwie touchpid 5470 otworzył plik.

Jeśli chcesz uzyskać więcej informacji, możesz uruchomić w „trybie przechwytywania”, w którym gromadzone są dane śledzenia połączeń systemowych:

# sysdig -w /tmp/dumpfile.scap

Następnie poczekaj na utworzenie pliku, a następnie zatrzymaj się sysdigi uruchom:

# csysdig -r /tmp/dumpfile.scap

To pozwoli ci odkryć wszystko, co się wydarzyło. Możesz nacisnąć <F2>i wybrać Files, naciśnij, <F4>aby wyszukać nazwę pliku, a następnie naciśnij, <F6>aby „wykopać” (co spowoduje wyświetlenie wyników podobnych do powyższych poleceń). Dzięki temu możesz następnie zastosować to samo podejście do znalezienia informacji o procesie, który faktycznie utworzył plik.

Istnieje wersja GUI o csysdignazwie sysdig-inspect, jeśli to bardziej twoja filiżanka herbaty.


a może zajętą ​​pętlę, która ciągle uruchamia lsof, próbując sprawdzić, czy / kiedy proces zapisuje do tego pliku ... unix.stackexchange.com/a/13782/8337
— rogerdpack

2

Nie masz, inotifywięc możesz napisać skrypt, który sprawdza plik w pętli:

#!/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
To nie pokazuje, jaki program to stworzył
— OverCoder
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.