[HELP] Ищется файловый монитор

Идея патчить ядро мне таки не нравится. Я бы предпочел модуль.
Хотя какие из этого подводные камни вылезут не знаю.
Для начала чем плоха идея врапперов для сисколлов?

> Идея патчить ядро мне таки не нравится. Я бы предпочел модуль.

нет, ну ясен пень, что идея патчить ядро пользователю системы по всей очевидности понравится меньше всего. она и мне совсем не нравится. патчить и пересобирать ядро на боевом RHEL4? это нонсенс. так что требование работы системы out-of-box без вмешательства пользователя/администратора - это вполне здоровое и понимаемое требование. как прямое следствие, та часть системы, которой по штату необходим доступ к внутренностям ядра должна грузиться как модуль.

> Хотя какие из этого подводные камни вылезут не знаю.

ну начнём хотя бы с того, что для корректной работы в многопроцессорной среде - да и в однопроцессорной в принципе то-же с включённой опцией preemptable - все интересующие нас объекты ядра защищены соотв. блокировками. это и dcache_lock для подситемы dentry cache, и files_lock для управления файловыми сессиями и sb_lock для списка суперблоков, vfsmount_lock для деревьев монтирования и так далее.

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

проблема в том, что авторы ядра не потрудились сделать интересные нам переменные экспортируемыми в модули, а некоторые из них и подавно объявлены статически. собственно из доступных блокировок есть лишь одна - это dcache_lock да и то видимо лишь в силу того, что многие функции для работы с dentry cache определены в <linux/dcache.h> как встроенные и но при этом используют указанную блокировку.

даже если какой-то символ ядра объявлен как глобальный но при этом явным образом не экспортируется в модули через макрос EXPORT_SYMBOL(), напрямую он модулю не доступен. его конечно можно объявить в коде модуля как extern foo, но это ничего не даст бо яжреный загрузчик модулей его все равно не будет ресолвить и наш модуль попросту не загрузится.

как вы будите решать эту маленькую дилему? :)

> Для начала чем плоха идея врапперов для сисколлов?

обёртка для системных вызовов конечно имеет право на существование, но для перехвата активности файловой системы это слишком грубый инструмент. даже перехватив sys_open() всё, что вы получите - это путь к файлу зачастую относительный и в неудобоваримом формате. сделать из него чистый абсолютный путь не столь тривиальная задача и в том числе она требует доступа к блокировке vfsmnt_lock. а перехват sys_read() или sys_write() вам даст ещё меньше бо для идентификации объекта они уже оперируют файловым дескриптором в таблице открытых файлов текущего процесса и грамотный перевод fd -> FS object то-же не столь тривиальная задача. а что вы будите делать с файлами, которые отображаются в память? о том, что процесс записал в отображённую область памяти какие-то данные и они потом скинулись на файловую системы вы оперируя лишь системными вызовами по всей очевидности не узнаете... :) да много там в принципе проблем если покопаться.

главная проблема IMHO - это то, что VFS в Linux совершенно не пригоден к таким трюкам by design. это ни хороши и ни плохо, просто это так есть so нужно быть готовым к разного рода извратам в процессе впихания в невпихуемое. но при определённой настойчивости оно туда таки впихивается :)

// wbr

Начнем по пунктам :)


>ну начнём хотя бы с того, что для корректной работы в многопроцессорной
>среде - да и в однопроцессорной в принципе то-же с включённой опцией
>preemptable - все интересующие нас объекты ядра защищены соотв.
>блокировками. это и dcache_lock для подситемы dentry cache, и
>files_lock для управления файловыми сессиями и sb_lock для списка
>суперблоков, vfsmount_lock для деревьев монтирования и так далее.

man что ты сказал? Я ж говорил - я дерево глупоеб неотесанное:)))

>даже если какой-то символ ядра объявлен как глобальный но при этом
>явным образом не экспортируется в модули через макрос EXPORT_SYMBOL(),
>напрямую он модулю не доступен. его конечно можно объявить в коде
>модуля как extern foo, но это ничего не даст бо яжреный загрузчик
>модулей его все равно не будет ресолвить и наш модуль попросту не
>загрузится.
>
>как вы будите решать эту маленькую дилему? :)

Да вобщем то на моем уровне познания - развье что что то типа трюка
с динамическим поском sys_call_table на заргузке модуля.

>нужно быть готовым к разного рода извратам в процессе впихания в
>невпихуемое. но при определённой настойчивости оно туда таки
>впихивается :)

Вот уж к этому всегда готов.:)

Вобщем для начала что ман. И наверное идеи с какого угла начать.
Ибо читать ман чисто теоретически идея полезная но не очень продуктивная.

>главная проблема IMHO - это то, что VFS в Linux совершенно не пригоден к таким трюкам by design. это ни хороши и ни плохо, просто это так есть so нужно быть готовым к разного рода извратам в процессе впихания в невпихуемое. но при определённой настойчивости оно туда таки впихивается :)

А ему и не нужно. Задача автора прекрасно решается с помощью systemtap. Я бы сказал, что она вообще решается с помощью audit, но если он хочет увидеть низкоуровневые потоки, то systemtap. Это, конечно, потребует знания ядра... на детском уровне есть еще упомянутый кем-то выше blktrace.

> man что ты сказал? Я ж говорил - я дерево глупоеб неотесанное:)))

man в ядре Linux? простите, но это утопия :)))
нет, боюсь разочаровать вас, но в Linux фактически отсутствует man -s9. впрочем, как и вменяемая документация или же описание большинства интерфейсов ядра. в лучшем случае редкие отрывки уровня "как мы ходили с друзьями на Гари Поттера". c'est la vie.

> Да вобщем то на моем уровне познания - развье что что то типа трюка
с динамическим поском sys_call_table на заргузке модуля.

hm.. трюк на тему "поиск заданного неэкспортируемого символа в памяти ядра из контекста модуля" в общем случае существенно более сложная задача, нежели сравнительно тривиальный поиск таблицы системных вызовов и подстановка в ней своих обработчиков. а если требуемый символ - это переменная, как в нашем случае блокировки, aka располагается в секции данных, то задача становится совсем не такой тривиальной. и даже если вы найдёте таблицу kallsyms она вам всё равно не поможет [в ней ссылки только на секции кода]...

> Вобщем для начала что ман.

ну как я уже сказал выше, man тут к сожалению помощник весьма так себе. что он есть [в таком виде], что его нет - фиолетово.

> И наверное идеи с какого угла начать.

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

>Ибо читать ман чисто теоретически идея полезная но не очень продуктивная.

применимо к ядру Linux она бессмысленна даже чисто теоретически ;)
это вам не Solaris с их DDI.

// wbr

> А ему и не нужно. Задача автора прекрасно решается с помощью systemtap.

это что за зверь такой?

> Я бы сказал, что она вообще решается с помощью audit,

по всей видимости имеется ввиду sys_write()->vfs_write()->SELinux->security_file_permission(file, MAY_WRITE)? а что это даст в плане ответа на вопрос "какое приложение в какой файл пишет"? как минимум нужна достаточно вумная надстройка.

> но если он хочет увидеть низкоуровневые потоки, то systemtap. Это, конечно, потребует знания ядра...

> на детском уровне есть еще упомянутый кем-то выше blktrace.

на этого зверя я как-то не смотрел.

// wbr

Нет я конечно тупой но не настолько. man я использовал в переносном
смысле. Что мана нет понятно. Но есть же LDD, Understanding Linux Kernel,
статьи наконец.
Не начинать же с прочти все.

Насчет трюка с динамическим поиском - прото этот трюк я видел и он единственный который я знаю.

По пунктам - по мере усложнения (ИМХО):
Отслеживать:
1) Создание удаление файла.
2) Открытие закрыте.
3) Чтение и запись.
4) mmap и ему подобные.
Требуемая информация 1,2 - pid и полный путь;3,4 - тоже самое + смещение в файле и обьем данных.

Дополнение/критика приветствуются.

>ну начнём хотя бы с того, что для корректной работы в многопроцессорной среде - да и в однопроцессорной в принципе то-же с включённой опцией preemptable - все интересующие нас объекты ядра защищены соотв. блокировками. это и dcache_lock для подситемы dentry cache, и files_lock для управления файловыми сессиями и sb_lock для списка суперблоков, vfsmount_lock для деревьев монтирования и так далее.

Вообще-то, помимо spin-блокировок есть "спящие" примитивы (в т.ч. в VFS) синхронизации ядра (семафоры, мьютексы и т.д.), которые и в UP задолго без PREEMPT существовали и были необходимы. :) Так что упоминание PREEMPT тут малость не в тему...

>проблема в том, что авторы ядра не потрудились сделать интересные нам переменные экспортируемыми в модули, а некоторые из них и подавно объявлены статически. собственно из доступных блокировок есть лишь одна - это dcache_lock да и то видимо лишь в силу того, что многие функции для работы с dentry cache определены в <linux/dcache.h> как встроенные и но при этом используют указанную блокировку. даже если какой-то символ ядра объявлен как глобальный но при этом явным образом не экспортируется в модули через макрос EXPORT_SYMBOL(), напрямую он модулю не доступен. его конечно можно объявить в коде модуля как extern foo, но это ничего не даст бо яжреный загрузчик модулей его все равно не будет ресолвить и наш модуль попросту не загрузится.

Эта проблема на практике для решения конкретной поставленной задачи очень просто разрешается с помощью ld + System.map

>обёртка для системных вызовов конечно имеет право на существование, но для перехвата активности файловой системы это слишком грубый инструмент. даже перехватив sys_open() всё, что вы получите - это путь к файлу зачастую относительный и в неудобоваримом формате. сделать из него чистый абсолютный путь не столь тривиальная задача и в том числе она требует доступа к блокировке vfsmnt_lock. а перехват sys_read() или sys_write() вам даст ещё меньше бо для идентификации объекта они уже оперируют файловым дескриптором в таблице открытых файлов текущего процесса и грамотный перевод fd -> FS object то-же не столь тривиальная задача. а что вы будите делать с файлами, которые отображаются в память? о том, что процесс записал в отображённую область памяти какие-то данные и они потом скинулись на файловую системы вы оперируя лишь системными вызовами по всей очевидности не узнаете... :) да много там в принципе проблем если покопаться.

Что касается файлов, отображенных в память, то тут ситуация принципиально ничем не отличается от ОС, где стек ввода-вывода более модульный. Просто контекст ввода-вывода будет системным. В Linux нет пакетов ввода-вывода, чтобы отследить как и куда пришел запрос на ввод-вывод, но это не означает, что из элеватора нельзя раскрутить стек и увидеть, откуда мы в него попали - в systemtap для этого есть стандартные функции. Вот если есть необходимость изменять поток ввод-вывода, тогда тут Linux и правда представляет не очень много средств и хотя они существуют, это тема для отдельного разговора. ;)

>это что за зверь такой?

Это наш аналог dtrace. В том же opensuse 10.2 есть в пакетах (правда, подразумевают сборку ядра с символами для отладки). В ядро встраивается с помощью механизма kprobes (примерно так, как это делают отладчики - привет int 0x3).

>по всей видимости имеется ввиду sys_write()->vfs_write()->SELinux->security_file_permission(file, MAY_WRITE)? а что это даст в плане ответа на вопрос "какое приложение в какой файл пишет"? как минимум нужна достаточно вумная надстройка.

В Linux есть стандартный модуль аудита. Как правило дистрибутивы идут и с userspace начинкой для него (audit, man auditctl).

>на этого зверя я как-то не смотрел.

Ну как же. В ветке же писали (sysctl -w vm.block_dump=1).

В смысле что простейший tracer, который активируется через sysctl - это еще не blktrace, но по сути примерно одно и то же. Скачайте соответствующий пакет и посмотрите.

> Нет я конечно тупой но не настолько. man я использовал в переносном
смысле. Что мана нет понятно. Но есть же LDD,

LDD вещь бесспорно хорошая, но в силу своей Driver направленности тема VFS в LDD не раскрыта. что впрочем не означает, что с этой книгой не стоит ознакомиться. IMHO написана она весьма грамотно и содержит массу полезной информации.

> Understanding Linux Kernel,

ULK вещь так себе, нечто на уровне man-а или Documentation ;) и тема VFS в ней аналогично не раскрыта, разве что самые-самые вершки. но ознакомиться впрочем то-же не помешает.

> статьи наконец.

ну да, ну да... :))) "блажен кто верует"

> По пунктам - по мере усложнения (ИМХО):
> Отслеживать:
> 1) Создание удаление файла.

это в принципе делается даже на уровне перехвата sys_open() и sys_unlink(). но что там произошло в результате успешного вызова оригинального обработчика и что от него вообще хотели думать придётся вам. и не забывайте про race conditions такого подхода бо после того, как вы получили управление обратно из оригинального обработчика файловая система в общем случае может находиться в произвольном состоянии и на момент выхода только что созданный файл может быть уже кем-то удалён ;) процесс то асинхронный, по крайней мере относительно перехваченного обработчика системного вызова.

> 2) Открытие закрыте.

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

> 3) Чтение и запись.

и даже это можно в принципе перехватить и привязать в fd. но не все чтение/запись идут через read(2)/write(2).

> 4) mmap и ему подобные.

а вот с mmap на уровне системных вызовов никак. причём что пользуется он приложениями и libc весьма активно :) в сущности при каждом запуске исполняемого mmap-а там 95% и из образа через read(2) читается разве что заголовок ELFа да и то скорее лишь для того, чтобы определить что это ELF.

> Требуемая информация 1,2 - pid и полный путь;3,4 - тоже самое + смещение в файле и обьем данных.

как вы свяжете fd переданный в sys_write() с fd, который когда-то вернул вам для заданной задачи вызванный ею sys_open()? вам же нужна информация в форме "приложение vim записало в файл /tmp/foo 10 байт данных [их дамп] по смещению 456". формулировка "-//- в дескриптор 7 -//-" не столь полезна и скажем так не совсем наглядна. причём что в силу dup2(2) значение дескриптора может быть уже совсем другим so его по всей видимости то-же стоит перехватить и обработать... ;)

> Дополнение/критика приветствуются.

ну уж если браться мониторить, то мониторить всё, правда? и изменение дерева файловой системы включая атрибуты, и удаление/создание директорий, и перенос файлов/директорий (rename) и монтирование/размонтирование включая извраты с mount --bind, и пр. радости жизни.

// wbr

> Вообще-то, помимо spin-блокировок есть "спящие" примитивы (в т.ч. в VFS) синхронизации ядра (семафоры, мьютексы и т.д.), которые и в UP задолго без PREEMPT существовали и были необходимы. :) Так что упоминание PREEMPT тут малость не в тему...

да глобальных семафоров или мьютексов в VFSе как раз кот наплакал, всё видимо в угоду эффективности сделано на спинлоках (spinlock_t). что впрочем не суть важно, бо что спрятанный где-то там семафор, что спинлок - один черт проблема с поиском и хрен редьки не слаще.

> Эта проблема на практике для решения конкретной поставленной задачи очень просто разрешается с помощью ld + System.map

на практике как раз /boot/System.map может или отсутствовать [благо для работы системы она не нужна] или же быть попросту некорректной [банально от другого ядра]. и проверить корректность подсунутой пользователем карты памяти в рантайме мягко говоря не просто [если вообще возможно]. tested ;)

System.map сильно помогает на лабораторном столе, когда что-то отлаживается здесь и сейчаc [тот-же поиск "чего-то тама" в памяти] как контролирующий орган мол мы это нечто действительно нашли или же нет. та-же таблица ksyms или syscall_table. но вот на практике требовать от конечного пользователя наличия корректного System.map проходит не всегда и полагаться на это IMHO не стоит. система должна прекрасно работать и без System.map.

да, но это уже конечно требования, которые выходят за рамки "посмотреть что там творится здесь и сейчас под тщательным и вменяемым присмотрим". это уже требования к Enterprise системе :)

> Что касается файлов, отображенных в память, то тут ситуация принципиально ничем не отличается от ОС, где стек ввода-вывода более модульный. Просто контекст ввода-вывода будет системным. В Linux нет пакетов ввода-вывода, чтобы отследить как и куда пришел запрос на ввод-вывод, но это не означает, что из элеватора нельзя раскрутить стек и увидеть, откуда мы в него попали - в systemtap для этого есть стандартные функции. Вот если есть необходимость изменять поток ввод-вывода, тогда тут Linux и правда представляет не очень много средств и хотя они существуют, это тема для отдельного разговора. ;)

у меня как раз задача в том числе иметь возможность их изменять... ;)

// wbr

Насчет systemtap. Простейший пример:

censored:/usr/share/systemtap/tapset # stap -e 'probe kernel.function("do_wait") { print_backtrace() }'
trace for 4772 (mono)
 0xc01230aa : do_wait+0x7/0x9bb []
 0xc02c4455 : kprobe_exceptions_notify+0x191/0x3f4 []
 0xc02c4faf : notifier_call_chain+0x20/0x31 []
 0xc012d14a : atomic_notifier_call_chain+0xb/0xd []
 0xc02c4190 : do_int3+0x49/0x80 []
 0xc02c3e3e : int3+0x1e/0x30 []
 0xc0123a84 : sys_wait4+0x26/0x2a []
 0xc0123a9b : sys_waitpid+0x13/0x15 []
 0xc0103ddd : sysenter_past_esp+0x56/0x99 []

Разумеется, этим возможности не исчерпываются.
Для всех системных вызовов прототипы прописаны,
для остальных интересующих функций (для ядра или своего модуля) 
это надо сделать самостоятельно (прототип набирается на С в guru-mode).

В общем, забавная штука. Рекомендую.

>да глобальных семафоров или мьютексов в VFSе как раз кот наплакал, всё видимо в угоду эффективности сделано на спинлоках

Глобальных то да, а вот неглобальных (если что-нибудь конкретное хотите пощупать/поменять) не так уж и мало: :)

censored:/ # find /usr/src/linux-2.6.18.2-34/fs/ -maxdepth 1 -exec grep mutex_lock {} \; | wc -l 130

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

Тут с вами сложно спорить. :) Бывали неприятные моменты в жизни, связанные с этим, хотя на практике с этим проблемы очень редко (знающий да предупрежден).

> В общем, забавная штука. Рекомендую.

да, судя по описанию, systemmap забавная штуковина. по крайней мере стоит посмотреть, что там придумали внутри. правда судя по их install:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~//src/README?cvsroot=s...

..приделать это as-is в production environment на стороне клиента скажем так.. не просто ;) впрочем, можно посмотреть на некоторые идеи и если понравиться позаимствовать.

спасибо за ссылку, до сих пор я как-то не общался с этим инструментом.

// wbr

>на практике как раз /boot/System.map может или отсутствовать [благо для работы системы она не нужна] или же быть попросту некорректной [банально от другого ядра]. и проверить корректность подсунутой пользователем карты памяти в рантайме мягко говоря не просто [если вообще возможно]. tested ;) >System.map сильно помогает на лабораторном столе, когда что-то отлаживается здесь и сейчаc [тот-же поиск "чего-то тама" в памяти] как контролирующий орган мол мы это нечто действительно нашли или же нет. та-же таблица ksyms или syscall_table. но вот на практике требовать от конечного пользователя наличия корректного System.map проходит не всегда и полагаться на это IMHO не стоит. система должна прекрасно работать и без System.map.

По-моему, испорченный или отсутствующий System.map - это как раз показатель неопрятной экспериментальной лаборатории. Вменяемые дистрибутивы при установке ядра устанавливают и System.map и config. При сборке и установке ядра вручную (make install) разработчиком тоже, в общем-то, устанавливается System.map. Ну а если вышел конфликт имен, то за такое надо бить по рукам.

То, что это метод академичный, вы может убедиться, проверив, что его использует, например, ps (ps -eo comm,wchan; man ps).

> Глобальных то да, а вот неглобальных (если что-нибудь конкретное хотите пощупать/поменять) не так уж и мало: :)

> censored:/ # find /usr/src/linux-2.6.18.2-34/fs/ -maxdepth 1 -exec grep mutex_lock {} \; | wc -l 130

ну неглобальные объекты синхронизации aka как часть какого-то другого объекта проблем не вызывают. inode->i_mutex как пример. ведь если есть объект - inode - то очевидно есть и его mutex :)

ps: собственно из этих 130 вхождений i_mutex занимает львиную часть.. ;)

foo@localhost: grep i_mutex /pub/kernel/2.6.16.20/fs/* | wc -l
116

> Тут с вами сложно спорить. :) Бывали неприятные моменты в жизни, связанные с этим, хотя на практике с этим проблемы очень редко (знающий да предупрежден).

чтобы банально пройтись по списку открытых файлов обязательно нужен держать files_lock иначе 1 из порядка 10ти экспериментов ведёт к панике. а на том же RHEL3/4 files_lock нифига не экспортируется в модули и это не смотря на то, что ванильное ядро это делает :-/

// wbr

Умны дяди посоветуют малым мира сего что почитать/посмотреть
чтобы просветиться?
Пока сам помытаюсь что нибудь найти про VFS.

>ну неглобальные объекты синхронизации aka как часть какого-то другого объекта проблем не вызывают. inode->i_mutex как пример. ведь если есть объект - inode - то очевидно есть и его mutex :) >ps: собственно из этих 130 вхождений i_mutex занимает львиную часть.. ;)

Как-то вы глобально подошли к вопросу. :) В общем-то, моей целью не было проанализировать, какие примитивы синхронизации используются в VFS, скорее уточнить, что необходимость синхронизации - более общая проблема, нежели проблема многопроцессорности или архитектуры вытесняемого ядра. ;)

>чтобы банально пройтись по списку открытых файлов обязательно нужен держать files_lock иначе 1 из порядка 10ти экспериментов ведёт к панике. а на том же RHEL3/4 files_lock нифига не экспортируется в модули и это не смотря на то, что ванильное ядро это делает :-/

Угу. Есть такое. Именно поэтому я стараюсь по минимуму контактировать с VFS. Нужен список файлов для ФС - лучше я сделаю внутренний список, чем буду разбираться в дебрях VFS, которые постоянно меняются. Чем меньше завязан на VFS, тем лучше. Но даже при этом постоянно всплывают проблемы. Например, при переезде на 2.6.18 изменился интерфейс rbtree (фигня вроде), scsi (дремучий лес) и по мелочам, например, statfs вместо суперблока теперь принимает dentry (порт даже до crash теста не дошел, свалившись в монтировании, которое изнутри использует statfs).

> По-моему, испорченный или отсутствующий System.map - это как раз показатель неопрятной экспериментальной лаборатории. Вменяемые дистрибутивы при установке ядра устанавливают и System.map и config. При сборке и установке ядра вручную (make install) разработчиком тоже, в общем-то, устанавливается System.map. Ну а если вышел конфликт имен, то за такое надо бить по рукам.

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

> То, что это метод академичный, вы может убедиться, проверив, что его использует, например, ps (ps -eo comm,wchan; man ps).

--- cut ---
This ps needs access to namelist data for proper WCHAN display. For kernels prior to 2.6, the System.map file must be installed.
--- cut ---

не исключаю, что он может использовать и /proc/kallsyms дабы таковой есть. хотя в man-е на эту тему ничего нет. в конечном итоге, форматы обоих файлов практически одинаковые и если банально кинуть симлинк /proc/kallsyms -> /boot/System.map то ps возможно сможет это проглотить [если отфильтрует названия модулей]. я так понимаю, что адреса символов в секции данных нужны разве что отладчику [если вообще нужны] и тут действительно нужна полная карта памяти. а для остальных kallsyms для бектрейса вполне хватает.

// wbr

> Умны дяди посоветуют малым мира сего что почитать/посмотреть
чтобы просветиться? Пока сам помытаюсь что нибудь найти про VFS.

ну начать можно действительно с LDD и ULK. там конечно скупо но как-то да описана общая идея. после почерпнуть полезного из штатной документации ядра в Documentation/filesystems/vfs.txt причём брать его от чем свежее тем лучше бо со временем сей файл как-то но дополняется. ну а дальше брать исходники и смотреть, как все это чудо работает бо первые два источника в лучшем случае дадут лишь весьма общее представление на уровне идеи но не более.

// wbr

>Умны дяди посоветуют малым мира сего что почитать/посмотреть чтобы просветиться? >Пока сам помытаюсь что нибудь найти про VFS.

Хоть я и не умный дядя, но выскажу мысль, что никто не знает, как оно работает и главное - почему оно работает. :) Лучше, IMHO, потратить время на изучение чего-нибудь более полезного и приземленного, чем реализацию нездоровых идей в ее эволюции. Если для общего развития, то можно почитать что-нибудь из классики. Кажется, у Макьюзика были неплохие книги о 4.3BSD и 4.4BSD. Хотя это уже исторические экспонаты, но концептуально(!) все не так уж и далеко ушло. :)

Вот так выглядит упомянутый blktrace:

censored:/usr/src/blktrace/doc # blktrace -d /dev/hdc -o - | blkparse -i -
 22,0    0        1     0.000000000  4761  Q   W 81856913 + 8 [konqueror]
 22,0    0        2     0.000015592  4761  G   W 81856913 + 8 [konqueror]
 22,0    0        3     0.000020447  4761  P   R [konqueror]
 22,0    0        4     0.000022305  4761  I   W 81856913 + 8 [konqueror]
...
 22,0    0      723    28.073699638  4752  D   W 65074617 + 96 [kopete]
 22,0    0      724    28.073734555  4752  U   R [kopete] 2
 22,0    0      725    28.074285352     0  C   W 65074617 + 96 [0]
 22,0    0      726    28.074305974     0  I   R 0 + 0 [swapper]
 22,0    0      727    28.074306207     0  I   W 65074713 + 8 [swapper]
 22,0    0      728    28.074306646     0  I   R 0 + 0 [swapper]
 22,0    0      729    28.074306872     0  D   R 0 + 0 [swapper]
 22,0    0      730    28.074340042  4752  U   R [kopete] 1
 22,0    0      731    28.083834189     0  D   W 65074713 + 8 [swapper]
 22,0    0      732    28.083947116     0  C   W 65074713 + 8 [0]
 22,0    0      733    28.083948668     0  D   R 0 + 0 [swapper]
 22,0    0      734    28.092232231     0  C   W 65074713 + 8 [0]
CPU0 (22,0):
 Reads Queued:           0,        0KiB  Writes Queued:         206,    1,376KiB
 Read Dispatches:       20,        0KiB  Write Dispatches:       68,      824KiB
 Reads Requeued:         0               Writes Requeued:         0
 Reads Completed:        0,        0KiB  Writes Completed:       78,      864KiB
 Read Merges:            0               Write Merges:          138
 Read depth:            20               Write depth:             1
 IO unplugs:            33               Timer unplugs:           7

Throughput (R/W): 0KiB/s / 30KiB/s
Events (22,0): 734 entries
Skips: 0 forward (0 -   0.0%)

Примерное ТЗ:

Нужно приложение, которое выдаёт в реальном режиме времени все операции чтения и записи данных как в файловой системе, так и напрямую на блочные устройства (чтобы, например, можно было отследить работу dd if=/dev/hda).

Формат вывода:

Номер_операции Время приложение тип_операции путь результат_операции количество_байт

Например,

1 14:52:11.55 cat write /tmp/file SUCCESS(0) 1024 2 14:54:33.18 chmod chmod /tmp/file SUCCESS(0) chmod(640)

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

Очень неплохо.

Только он, наверное, не даёт статистики по всяким левым операциям а-ля fopen, unlink, chmod, chown, mount и т.п.

Пора эту тему в Development перекинуть.

В общем, я так чувствую, что filemon для 2.6.x - это утопия.

есть предложение перенести это обсуждение хотя бы в Development. в Talks слишком активная ротация тем а каждый раз искать ветку в архивах не хочется.

// wbr

> В общем, я так чувствую, что filemon для 2.6.x - это утопия.

ну это на самом деле совсем не утопия и версия Linux - 2.4/2.6 без разницы - тут особой роли не играет.

// wbr

>Только он, наверное, не даёт статистики по всяким левым операциям а-ля fopen, unlink, chmod, chown, mount и т.п. >Пора эту тему в Development перекинуть. >В общем, я так чувствую, что filemon для 2.6.x - это утопия.

Зря вы так плохо думаете. Давайте прикинем архитектуру всей это байды, чтобы проще было придумать решение.

Нить -> vfs, mm -> fs -> elevator -> блочное устройство.

Нас интересует: 1) интерфейс системных вызовов для работы с файлами 2) интерфейс запроса файловой системы к elevator и от elevator к блочным устройствам.

По пункту 2 кое-что есть (block_dump - плюет в kernel log, blktrace - плюет в файл).

По пункту 1 есть предложение попользовать audit(демон auditd плюет в файл) или systemtap (плюет в файл). Поскольку шаблона "работа с файлами" там нет, то придется прописать ручками все интересные вам системные вызовы.

Соответственно, можно: 1) запустить blktrace с нужными параметрами 2) запустить audit с нужными параметрами (системные вызовы) 3) подождать 4) пропустить через фильтр вывод blktrace 5) пропустить через фильтр вывод audit

Готового продукта, вероятно, нет, но склепать что-нибудь можно, если есть реальная необходимость.

> Готового продукта, вероятно, нет, но склепать что-нибудь можно, если есть реальная необходимость.

Костыли всё предлагаете. Хочется что-то работающее в отсутствие SeLinux.

> Костыли всё предлагаете. Хочется что-то работающее в отсутствие SeLinux.

тем более, что функциональность SELinux вам не поможет :) причина проста - это *пре* фильтр. он проверяет, может ли быть исполнена запрашиваемая операция или нет. очевидно, до исполнения самой операции. и естественно не отвечает на вопрос о том, что произошло с операцией после того, как её пропустил через себя SELinux :)

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

// wbr

Это всё ясно, кто-то этим всё-таки займётся?

> Это всё ясно, кто-то этим всё-таки займётся?

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

ps: ответ "шоб було" скорее всего не подойдет.

// wbr