Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Клуб юнуксоидов > Помогите с письмом, а

Автор: GrayCardinal 27.10.2005, 11:04

В общем в ядрышке 2.6.13 есть такая фишка, называется inotify. (Documentation/filesystems/inotify.txt) Суть вопроса , собственно, почему туда PID (т.е. того юзера, кто, собственно доступ осуществлял) процесса не припахали ?! Отслеживать триста тыщ файлов, это конечно, хорошо (я тащился), но ведь это ж еще не вся "хакерская мечта" Братья линуксоиды, которые писали inotify : John McCutchan <[email protected]> Robert Love <[email protected]> ЗЫ Я б с удовольствием им сам написал, только с инглишем у меня полный "упс". ЗЫЫ Вот сижу и наблюдаю как какой-то процесс каждые 2 сек. дергает /etc/mtab. А отрубить не могу, ибо не знаю какой процесс

Автор: bilbobagginz 27.10.2005, 16:49

вопрос1: с каких это пор PID связан с UID/GID ? процесс - сдох, и его PID занял другой. вопрос2: ты по-моему не догнал факт, что чаще всего до файла дотрагиваются не процессы юзера а всякие там демоны из серии kswapd и его собратья. в таком случае - нафига тебе знать что файл засвопился или рассвопился ? кроме того, цель проекта не создать инфраструктуру слежения за юзерами, а слежения за изменениями в файловой системе, и если тебе надо, то пиши патч, и отошли его Роберту Лову, или его товарищу по парте. а вообще я думаю, что процесс, к-рый дергает твой mtab, имеет связь с hald-ом пока.

Автор: GrayCardinal 28.10.2005, 10:13

Начал догонять. Сегодня прям с утра. Но еще не до конца. Не понял. как это никак не связан ? Берешь PID, лезешь в /proc/$PID и получаешь всю инфо по процессу (или тупо - "$ ps -aux"). Главное - консоль, к которой подключен. А без PID - ну никак. Ну читают твою "архиважную" информацию, а ты сидишь и тупо смотришь, а сделать ничего не можешь. Не, можно, конечно, выдернуть шнур... Нет, я могу понять, что писалось сие для того чтоб делать реакцию на изменения какого-нибудь файло. Конфига, к примеру, чтоб тупо не читать его каждые (условно) 5 сек. Но почему такая однополярность ? Пример. Короче делаю я слежение за созданием/удалением файлов в /etc/ Сижу, энто, администрирую. И вижу мессагу на консольке (условно) "удален /etc/passwd" (ну, скажем, кто-то дырку нашел на моем httpd, тупо запущенным под рутом) и шо, мне просто идти вешаться ? На счет второго вопроса. Цитата вопрос2: ты по-моему не догнал факт, что чаще всего до файла дотрагиваются не процессы юзера а всякие там демоны из серии kswapd и его собратья Не пойму я тебя чегой-то. Ты про какой своп-то ? у меня его отродясь не было (память позволяет) Вот что у меня при $ cat /etc/passwd -------------------------------------------------------------------------------- доступ к файлу /usr/share/icons/crystalsvg/16x16/actions/openterm.png доступ к файлу /bin/cat доступ к файлу /bin/cat доступ к файлу /bin/cat доступ к файлу /lib/ld-2.3.2.so доступ к файлу /lib/ld-2.3.2.so доступ к файлу /lib/tls/libc-2.3.2.so доступ к файлу /etc/passwd ----------------------------------------------------------------------------------- Это потому что я изгаляюсь, и слежу за всей системой (там "всего" 300т файлов...). Однако ведь можно включить только /etc/passwd, к примеру... А если какой демон файлы трогает, так это можно на этапе "конфигурирования" все файлики, которые должны "дергаться" в нормальном состоянии просто не включать... ЗЫ Письмо соображаю. ЗЗЫ Патч я б написал, боюсь пива не хватит

Автор: GrayCardinal 28.10.2005, 13:14

bilbobagginz Зря волновался, 0.5 хватило. Над письмом еще думаю (это оказалось сложнее )

Автор: bilbobagginz 28.10.2005, 14:13

Наконец-то интересная дискуссия развивается. Смотри, насколько я понимаю, inotify разрабатывали для оперделенных, сформулированных целей, и т.с. если у тебя они не соответствуют с нуждами, сам понимаешь... пиши сам, или проси Роберта. во вторых, эту систему разрабатывали как замену/оптимизацию dnotify, что об оригинальности не говорит. допустим ты сидишь и мудро смотришь на то как у тебя на консоли написано: изменился файл /bin/ls (установка rootkit-а) .. .. .. .. изменился файл /sbin/zsh (...) изменился файл /etc/shadow (поменяли пароль root) ну и для веселости: еще убили твой процесс оболочки, и ты с умным видом, через ssh был отключен. стабильность системы наживается при помощи многих факторов и систем ( как лук или капуста, много слоев и т.д. ); если тебе нужна безопасная система, а не утилитка для размонтирования дискетки или КД, то я думаю одним inotify все равно не обойдешься - с selinux нужно повозиться, вставить всякие пакости для проверки файлов и т.д., короче полный пакет, и особенно - восстановление из бекапов, ну и сами бекапы. Чтобы в случае того, что тебе делают вот эту сверху операцию без наркоза - реабилитация была с минимальный срок. Цитата Не пойму я тебя чегой-то. Ты про какой своп-то ? у меня его отродясь не было (память позволяет) не важно, какой-то другой демон файловой системы ( kjournald) могет дергать все файлы. я думаю, что проблема вот в чем: ты используешь inotify "не поназначению". насколько я вижу, это не инструмент безопасности, по планировке.

Автор: GrayCardinal 29.10.2005, 11:23

Патч ушел... С жуткой пометкой WHY NOT ? Надеюсь этого хватит. Если нет - будем думать дальше. ЗЫ А я таки достучался до "ядерщиков". Короче в -mm ветке последней не будет бага при добвлении модуля который уже встроен в систему. Короче, если у вас vfat встроена в систему, а вы пытаетесь подгрузить, vfat.ko, то BUG-а на два экрана больше не будет.

Автор: GrayCardinal 29.10.2005, 11:52

Цитата и особенно - восстановление из бекапов, ну и сами бекапы. Чтобы в случае того, что тебе делают вот эту сверху операцию без наркоза - реабилитация была с минимальный срок. То, что одним inotify тут не обойтись (тяжелый случай ), это понятно, конечно. Однако вариант с PID дает гораздо больше возможностей (и областей применения), не находишь ? .

Автор: bilbobagginz 29.10.2005, 12:41

да, согласен, но есть оговорки. давай, детали твоего патча обсудим в привате: детали разработки не интересны всем, а только нам, и поэтому об этом лучше не в форуме. P.S. если кто несогласен ( кроме GrayCardinal ) опровергните меня - тема - открыта.

Автор: Mayk 29.10.2005, 13:33

не надо привата. Этот топик интересно читать

Автор: GrayCardinal 30.10.2005, 07:45

bilbobagginz Ответ таки пришел. (видать часто ему этот вопрос задавали ) Цитата > 1) Security >       Letting processes know which pid is working with an inode is a huge > security leak. > > 2) ABI >       If we extend the event structure that will break every application that > uses inotify. That's unacceptable at this point.   Agreed. На второе, мне честное слово ... с большой колокольни Не нашел я что-то ни одной проги, котороя пользует inotify. Прошло каких-то пару месяцев всего. Пришлось свою писать Насчет первого. У кого паранойя ? У меня ? Понятно, что против стандартов не попрешь. Но, к примеру, кто мешает сделать эту фишку только для рут-а ? Я тебе "патч" отправил по асе. Не смотри патч, смотри суть

Автор: GrayCardinal 2.11.2005, 10:08

Вторая версия патча ушла, короче . Все "пожелания" были учтены. Посмотрим что они на _это_ скажут.

Автор: GrayCardinal 3.11.2005, 11:22

Короче, братцы, не будет у вас PID'а. Видно не судьба

Автор: GrayCardinal 3.11.2005, 12:06

Цитата процесс - сдох, и его PID занял другой. _Они_ мне то же самое написали. Млин, я ж не собераюсь координаты запуска ядерных ракет определять по этому долбаному PID Просто, к примеру, если мой бровзер загрузит страницу с ява-скриптом и начнет отсылать мой /etc/shadow на www.xakep.ru, я буду знать 1. Что /etc/shadow ушел налево 2. Дырка именно в этом бровзере Что, только мне это надо ? ЗЫ если прогу слежения найснуть (nice -n -20), черта-с два успеет умереть старый и создаться новый процесс.

Автор: bilbobagginz 3.11.2005, 13:35

Cardinal, пардон: Цитата(GrayCardinal) ЗЫ если прогу слежения найснуть (nice -n -20), черта-с два успеет умереть старый и создаться новый процесс. "черта-с два"!="никогда" когда ты найсишь процесс к-рый пишет на терминал/в файл, в конце концов ты увидишь в файле данные ПОСЛЕ того как произошел напр. fflush(). если когда изменение происходит в лог файл пишет кто-то длинную запись, то никто не обещает что твой write() или syslog() успеет написать в файл до того как произойдет следующий resched(). так, что ... не думаю что ты можешь такое утверждать. и вообще все записывается в какой-то буфер. обещается, что в конце концов запись будет в порядке сообщения, но когда именно функции записи вернутся - никто тебе не может сказать ( если ты используешь стандартную политику scheduling ) ладно изголятся: твоя утилитка полезна пока.

Автор: GrayCardinal 3.11.2005, 15:37

ОК. Кто мешает на этапе програмки ? Получил event-у, СРАЗУ снял всю нужную инфу по процессу. И вообще. Просто строчку дописать в документашку что "правильность не 100%-ная". И усе. ЗЫ. просто обидно стало за свое творчество

Автор: GrayCardinal 16.12.2005, 10:28

"Не успеет", "умрет не дожидаясь", новый создасться... "Если". Тьфу. А уменя процессы будут убиваться с уровня ядра... Вот тока сейчас пельменей схаваю да и найду как это правильно сделать ...

Автор: GrayCardinal 16.12.2005, 14:55

Цитата © Oleg Puchinin 2005 ([email protected]) Сборка без поддержки PID-функции. Запуск, пожалуйста ждите... OK 16.11 11:46:7 доступ к файлу /etc/passwd Цитата $ root@debian:/home/oleg# cat /etc/passwd Killed Вот так вот братцы. Вот так. Теперь моя душенька спокойна. Ха-ха.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)