1

Допустим есть директория с кучей поддиректорий и файлов, некое ПО изменяет часть содержимого текст. файла или бинарного, как и чем определить в каких файлах произошли изменения ?

XMPP: mogul82@jabber.ru Фанбой AMD

2

man find, внимание на -newer

95% процентов проблем находятся между клавиатурой и стулом.

3

если на лету, то с помощью inotify() и утилит на его основе.

4

mogul82 пишет:

Допустим есть директория с кучей поддиректорий и файлов, некое ПО изменяет часть содержимого текст. файла или бинарного, как и чем определить в каких файлах произошли изменения ?

Вычислять MD5-дайджесты и сравнивать с ранее запомненными значениями. Можно обойтись и CRC32, но оно сильно коллизионно и там без проблем можно спрятать изменения. С MD5-дайджестом такое не пройдет. Это классический подход к оффлайновому обеспечению контроля целостности.
Ну, можно и initifywait использовать. Там сразу будешь получать события файловой системы и знать, какой файл кто трогал. Это уже в онлайне.

5

gvfs-monitor-dir
gvfs-monitor-file

Leap 42.3 Calculate Linux, Xfce, Emacs, ..

6

по этой же теме интересно а можно ли как то узнать делалась ли копия файла ?

Спросить - стыд минуты, не узнать - стыд всей жизни

7

lone_wolf, практически никак. Момент чтения ты можешь зафиксировать. А также можешь зафиксировать момент создания нового файла и записи в него. Но как ты узнаешь, что это именно копирование было? А вдруг просто совпадение?

А так... inotify-tools вам в помощь =).

8

mogul82 пишет:

Допустим есть директория с кучей поддиректорий и файлов, некое ПО изменяет часть содержимого текст. файла или бинарного, как и чем определить в каких файлах произошли изменения ?

Кстати, а с какой целью интересуетесь? У вас стоить цель аудита некоей файлопомойки без принципиальноого измененения её концепции?
Или Вы пытаетесь организовать что-то вроде контролируемого (аудируемого) архива документов, где все шаги юзерей протоколируются? То есть - что именно хотите построить?
Если цель - просто обеспечить контроль целостности файлов, то стандартный путь - вести базу дайджестов и с помощью inotify перехватывать некоторые файловые события.
А если цель - создание корпоративного архива документов, то погуглите в сторону alfresco. Много чего умеет, но в части аудита регистрирует отдельно кто файл посмотрел, кто файл изменил и так далее.  Там много интересных ништяков имеется.

Мое резюме такое - не стоит изобретать велосипеды.

9

http://habrahabr.ru/post/81889/

+ открыть спойлер

tripwire


Это уже инструмент посерьезней. Он хранит снимок текущей файловой системы (вплоть до используемых файлами инодов) и рапортует любые изменения (привет любителям автоапдейтов).
Опять-таки:
apt-get install tripwire
Задаем при установке отдельно пароль для генерации ключей и полиси, и второй пароль для базы данных.
После установки правим файлы /etc/tripwire/twcfg.txt и /etc/tripwire/twpol.txt, делаем инициализацию БД:
tripwire --init
и запускаем пробную проверку
tripwire --check
На выходе получаете туеву хучу сообщений об отсутствующих файлах. В базовой поставке tripwire упоминаются все возможные варианты файлов, поэтому правите опять файл политик /etc/tripwire/twpol.txt и обновляете его:
tripwire --update-policy /etc/tripwire/twpol.txt
Опять-таки, как и в предыдущем случае, проверяем, ходит ли к вам почта:
tripwire --test --email адрес
и создаем в кроне задание с ключиком --email-report

Но не стоит расслабляться — если уж злоумышленник получит рутовые права на вашей тачке, то ему не составит труда просто переустановить tripwire со своими ключами, и вы будете все так же получать репорты в стиле «Все хорошо, прекрасная маркиза», пока в один прекрасный день не надумаете обновить конфиг или полиси и не получите сообщение о неверном пароле.

10 (08.12.2014 20:18:02 отредактировано mogul82)

Можно кстати через strace, трассировать обращения к файлам, определенного процесса по PID

 Консоль:
strace -e trace=open,read -p 5598 -o /media/sda9/text_file

Вывод в файл будет таким:

read(71, "m6 'xwd:%s'; test=test -n \"$DISP"..., 4096) = 513
read(71, "", 4096)                      = 0
open("/home/mogul/.local/share/mime/application", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 73
open("/home/mogul/.local/share/mime/video", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 73
read(71, "on/vnd.sun.xml.draw.template\t\t\t\t"..., 4096) = 4096

Можно -e trace=open,close,read,write

XMPP: mogul82@jabber.ru Фанбой AMD

11

mogul82 пишет:

Можно -e trace=open,close,read,write

Можно. Но не нужно. А именно - события open и read очень сильно загадят журнал. Но их ты никак нарушителю преъявить не сможешь. Более того, если нарушитель имеет немного мозгов, то он размажет тебя за такую предъяву как последнего лоха и будет совершенно прав.
А именно - аудит чтения файлов имел смысл тогда, когда деревья были большими, а компьютеры еще больше.  Сейчас-же производители программного обеспечения, графических файл-менеджеров, пошли настолько навстречу тупому юзеру, что предлагают насладиться ему видом миниатур содержимого файлов в каталоге в окне своих файл-менеджеров. Простой вопрос - эти миниатюры Дух Святой навевает? Или файл-менеджер незатейливо перебирает все файлы в каталоге, открывает их по очереди, считывает определенные (в зависимости от mime-типа файла) структуры и строит эти миниатюры.
И вот ситуация, ты, крутой такой весь из себя, засек, что кто-то прочитал файл. И начинаешь его прилюдно строить. А этот нехороший некто уличает тебя в незнании основ работы гуевых файл-менеджеров, говорит, что ничего он не читал из такого каталога, а только случайно его открыл. Чем и породил поток событий открытия-чтения файлов. И что, мол, ты сам, админ, - лох, так как если нельзя мне туда ходить, то почему есть у меня такая возможность?..
Одним словом - предъява гнилая, судебной перспективы не имеющая. Так как вылавливать из потока обозревательных открытий открытие файла умышленное... Ну, не самая тривиальная задача. Надо события по временам разносить, исключать одиночные в блоке события (ФМ читает файл только один раз) и так далее... Сложно всё это.