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.