LINUX.ORG.RU

Общение


0

0

Для иерархии процессов нужно вести учет всех измений файловой системы, которые они делают (на самом деле не только ФС, но для простоты положим что только). Код должен быть кросс-платформенным, по крайней мере работать под Linux и *BSD.

Первая идея такая - сделать библиотеку для LD_PRELOAD, перехватывать там системные вызовы open (на запись), mkdir, rmdir, link, unlink и т.д. В плане напечатать в STDOUT изменяемые файлы работает отлично. Но проблема в том, что процесс порождает кучу дочерних, и нужен способ собрать информацию со всей иерархии в одной точке. Как это можно сделать?

Самое логичное было бы сделать следующее: - запускается управляющая программа, создает сокет, запускает корневой процесс нашей иерархии с LD_PRELOAD - библиотека пишет все изменяемые файлы в сокет, управляющая программа читает, сортирует, фильтрует и пишет в лог.

проблема в следующем: как из библиотеки узнать путь к управляющему сокету? Через переменную окружения его передать не канает, потому что кто-то из процессов может очистить (и очищает, сука) окружение. Глобальный путь также не канает, потому что процессов может быть несколько. Есть какой-то надежный способ передать в потомков какие-либо данные?

Может еще какие-то способы есть? Думал про ptrace(2), но не факт что она сможет отловить все что мне надо.

PS. Сейчас подумалось, что можно перехватывать еще и функцию setenv и не давать изменить переменную с адресом к сокету. Как вариант?

anonymous

Не проще написать модуль специализированной ФС (возможно на базе fuse, которая есть и под фрю тоже)?

anonymous
()
Ответ на: комментарий от anonymous

Нет, на уровне ФС это не решить, потому что в те же директории могут писать другие процессы, плюс решение хочется прозрачное (на уровне `myfilemon make' вместо `make')

anonymous
()

> проблема в следующем: как из библиотеки узнать путь к управляющему сокету? Через переменную окружения его передать не канает, потому что кто-то из процессов может очистить (и очищает, сука) окружение.

а ты посмотри на процесс-родитель, а потом на родитель родителя и т д, пока не встретишь "cвоего"... c правильно установленной переменной?

gods-little-toy ★★★
()

А если кто-то окружение очищает, он же этим твою либу из LD_PRELOAD выкидывает и может потом форкнуться и из под присмотра уйти?

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

> а ты посмотри на процесс-родитель, а потом на родитель родителя и т д, пока не встретишь "cвоего"... c правильно установленной переменной?

Вариант.

> А если кто-то окружение очищает, он же этим твою либу из LD_PRELOAD выкидывает и может потом форкнуться и из под присмотра уйти?

Точно, поэтому я и думал влезть еще и в setenv.

Может правда лучше ptrace... Он не тормозит процесс, если перехватывать им сисколлы?

anonymous
()

> Первая идея такая - сделать библиотеку для LD_PRELOAD, перехватывать там системные вызовы

из библиотеки перехватывать системные вызовы? оригинально.

anonymous
()

Системые вызовы при помощи LD_PRELOAD перехватывать это сильно конечно. Я решил эту задачу взяв за основу исходники strace. Для того чтобы узакать где лежить некий файл в системе обычно делают конфиг файл в котором указывают данную информацию или фигачат по заранее определенному полному пути.

gena2x ★★★
()
Ответ на: комментарий от anonymous

> из библиотеки перехватывать системные вызовы? оригинально.
> Системые вызовы при помощи LD_PRELOAD перехватывать это сильно конечно.


Может уважаемые еще и поведают, в чем принципиальная проблема?

> Я решил эту задачу взяв за основу исходники strace.


ptrace, как я и думал. Надо изучить - думаю, будет лучше.

> Для того чтобы узакать где лежить некий файл в системе обычно делают конфиг файл в котором указывают данную информацию или фигачат по заранее определенному полному пути.


Нет.

anonymous
()

А не проще парсить аудит?

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.