On Thu, Mar 06, 2008 at 02:25:11AM +0300, Dmitry V. Levin wrote:
> On Sat, Mar 01, 2008 at 11:17:32AM +0300, Alexey Tourbin wrote:
> > Встал вопрос такого характера. :)
> > Как бы сделать чтобы в hasher'е /dev/log был больше похож на настоящий.
> [...]
> > [builder@solemn .in]$ logger -d -u /dev/log -p user.debug test &>/dev/null || echo no
> > no
> [...]
> > Это наводит меня на мысль, что в hasher'е не хватает ещё одной штуки --
> > типа "системного демона" (третьего псевдопользователя).  Системный демон
> > может частично эмулировать работу системных сервисов:
> > 1) что-то делать с /dev/log;
> 
> Для этого, пожалуй, третий псевдопользователь будет overkill'ом.
> Сейчас за прокачку данных через дескрипторы отвечает процесс, который
> работает с правами вызывающего hasher-priv пользователя.

> > 2) перехватывать через netlink обращения к внешней сети.
> Как ты себе это представляешь?

Я не очень хорошо знаю как работает netlink, поэтому представление
мое во многом интуитивное.  Варианта два: 1) слинковать hasher-priv с
iptables, чтобы он загружал ядерный модуль и выставлял цепочку правил,
которая отправляет исходящий трафик пользователя-сателита на netlink;
и потом форкался и запускал отдельный процесс, который прокачивает
данные из netlink'а в stderr.

2) Ввести системный сервис "поддержка хешера" (с init-скриптом и т.п.);
тогда вся боль по настройке ядерного модуля, цепочки правил и т.п.
ляжет на эот сервис, и в принципе это будет более конфигурабельно.
Тогда hasher-priv'у остаётся всего лишь послать stderr-десктиптор
в этот сервис, чтобы сервис в него писал.  Вроде через sendmsg(3)
можно как-то отправлять дескрипторы unrelated процессам.

> > "Что-то делать" или "перехватывать" здесь скорее всего означает просто
> > "выводить на stderr" пользователя builder (или rooter), на практике --
> > в лог сборки.
> 
> Выводить в stderr builder'у не стоит, лучше в stderr caller'у.

Я тут не совсем понял.  Оно в лог сборки попадёт или нет?
Что-то я немножко забыл, как все эти дескрипторы устроены.

> Разводить здесь полноценный syslog нет никакого желания, это точно.

Полноценный сислог (с поддержкой /etc/syslog.d) разводить всё равно
смысла нет, т.к. в чруте нельзя полноценно запускать чрутизированные
в свою очередь сервисы -- не хватит прав на chroot(2).