Можно ли узнать, какой программой или скриптом создан данный файл?


35

В моем домашнем каталоге неожиданно появились три файла: client_state.xml, lockfile и time_stats_log. Последние два пусты. Мне интересно, как они туда попали. Это не первый раз, когда это случилось, но последний раз это было несколько недель назад; Я удалил файлы и ничего не сломалось и не пожаловалось. Я не мог думать о том, что я делал в то время, о котором сообщал stat $filename. Могу ли я узнать, откуда они пришли?

Альтернативно, есть ли способ контролировать домашний каталог (но не подкаталоги) для создания файлов?


Так как я уверен, что кто-то упомянет об этом, у меня нет inotify.
Wolf

Ответы:


18

Я не верю, что есть способ определить, какая программа создала файл.

Ваш альтернативный вопрос: вы можете наблюдать за воссозданием файла, используя inotify. inotifywaitинтерфейс командной строки для inotifyподсистемы; вы можете сказать ему искать createсобытия в вашем домашнем каталоге:

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

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

Вы, вероятно, хотите запустить его с -m(monitor), который говорит не выходить после того, как увидит первое событие


Как я могу получить inotify? Он не установлен (ядро 2.6.34) и его нет /dev/inotify.
Wolf

1
@ Волк Какой дистрибутив? Если вы собираете свое собственное ядро, оно CONFIG_INOTIFY_USER( Filesystems-> Inotify support for userspace). inotifywaitвероятно, в пакете с именем что-то вродеinotify-tools
Майкл Мрозек

@ Майкл, это openSUSE 11.3. Я никогда не собирал ядро; Я использую Linux только около 5 месяцев, и это немного устрашающая концепция. Но я посмотрю вокруг для учебника или что-то.
Wolf

@ Wolf Что ж, ответ собачьей палочки может быть проще, если у вас нет ядра, которое у вас есть
Майкл Мрозек

2
@Michael На самом деле, после небольшого количества охоты и исследований, я добавил репозиторий сообщества, который, как оказалось, содержит inotify-toolsпакет, так что теперь у меня есть inotifywaitinotifywatch). Я проверил это, и это похоже на работу.
Wolf

22

Вы можете наблюдать за всем, что происходит в файловой системе, обращаясь к ней через LoggedFS . Это сложенная файловая система, которая регистрирует каждый доступ в дереве каталогов.

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

Регистрация всего домашнего каталога может замедлить работу вашей системы. Вы по крайней мере захотите написать файл конфигурации со строгими фильтрами.

Если у вас есть root-доступ, в Linux вы можете использовать подсистему аудита для регистрации большого количества данных, включая обращения к файловой системе. Убедитесь, что auditdдемон запущен, затем настройте то, с чем вы хотите войти auditctl. Каждая регистрируемая операция записывается в /var/log/audit/audit.log(в типичных дистрибутивах). Чтобы начать просмотр определенного файла:

auditctl -w /path/to/file

или в длинной форме

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

Если вы поместите наблюдение в каталог (с помощью -wили -F dir=), рекурсивно будут также просматриваться файлы в нем и его подкаталогах.


BSD также поддерживает это посредством аудита событий безопасности. freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html
Шон Дж. Гофф

4

Возможно, вы захотите взглянуть на auditdэтот пакет, который позволяет проводить аудит безопасности и получать много информации о том, кто что изменил в файловой системе.


если у вас есть сервер, который обеспечивает доступ к оболочке для нескольких пользователей, и вам необходимо обеспечить определенный уровень ответственности за отдельные действия, вы можете создавать определенные оболочки (например, bash и tcsh) с ведением журнала истории команд. Я написал сообщение в блоге о входе в оболочку на < timkennedy.net/2010/12/07/… >. Ведение журнала оболочки не является заменой реальной системы аудита, поскольку она не будет регистрировать команды, выполняемые неинтерактивными оболочками (такими как сценарии или программы). Чтобы получить такую ​​степень детализации, вам действительно нужно хорошее решение для аудита.
Тим Кеннеди

1
@TimKennedy - ваше сообщение в блоге больше не появляется.
SLM

1
Сожалею. Сайт был взломан и некоторое время не работал. новая страница находится на timkennedy.net/2010/12/logging-shell-commands-to-syslog-on.html
Тим Кеннеди

3

Я знаю, что это старый вопрос, но я предложу другой подход на тот случай, если кто-то сочтет его полезным. Я первоначально отправил это как ответ на вопрос, который был дублирован на этот.

Один из вариантов - использовать sysdig: приложение для мониторинга системы с открытым исходным кодом. Используя его, вы можете отслеживать активность файла по имени. Предположим, вы хотите увидеть, какой процесс создает файл с именем /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

Из этого вывода видно, что touchфайл с именем pid 5470 открыл файл.

Если вам нужна дополнительная информация, вы можете запустить в «режиме захвата», где собрана трассировка системного вызова:

# sysdig -w /tmp/dumpfile.scap

Затем дождитесь создания файла, затем остановитесь sysdigи запустите:

# csysdig -r /tmp/dumpfile.scap

Это позволит вам исследовать все, что произошло. Вы можете нажать <F2>и выбрать Files, нажмите, <F4>чтобы найти имя файла, затем нажмите, <F6>чтобы «копать» (который покажет вам вывод, похожий на команду выше). При этом вы можете использовать тот же подход, чтобы найти информацию о процессе, который фактически создал файл.

Есть версия GUI для csysdigзвонков sysdig-inspect, если это больше ваша чашка чая.


или, может быть, занятый цикл, который постоянно запускает lsof, пытаясь увидеть, если / когда процесс записывает в этот файл ... unix.stackexchange.com/a/13782/8337
rogerdpack

2

У вас нет, inotifyпоэтому вы можете написать скрипт, который проверяет файл в цикле:

#!/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
Это не показывает, какая программа его создала
OverCoder
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.