>[оверквотинг удален]
>>>> JFYI: rc.d системе NetBSD без разницы, из базовой системы взялся пакет или
>>>> из pkgsrc.
>>>> В обоих случаях chroot-ится демон одной строкой в rc.conf
>>> А что в netbsd чрутится?
>> Фактически в NetBSD создаётся такой полу-контейнер. Это неплохо, НО! если программа изначально
>> не рассчитана на работу в chroot (например, периодически обращается к чему-то
>> вовне, типа resolv.conf или какие-нибудь плагины открывает, с длинными цепочками зависимостей),
>> то в chroot надо помещать ещё пол-системы. И смысла уже большого
>> от этого нет, атакующий получает достаточно широкий спектр потенциально заюзываемых средств.
> В чем поинт? Ну да, чрут готовится самостоятельно, по вкусу.Я к тому, что если софтина изначально не рассчитана на chroot (при этом обычно умеет делать его сама), то засовывать её в chroot "извне" - сомнительная мера.
>> rc.d в OpenBSD создавалась в первую очередь из соображений минималистичности.
> Минималистичность, возведенная в абсолют, это аскетизм.
> Нужно соблюдать баланс между минималистичностью, удобством, и безопасностью.
> В случае rc.d безопасность вообще не релевантна.
Я про безопасность и не говорил, плз, читай внимательнее. Я как раз вам обоим пытаюсь втолковать, что rc.d в OpenBSD не планировалась и не планируется в виде развесистой клюквы. Только как единый интерфейс для запуска/перезагрузки/остановки сервисов. Всё, что "сверху", выходит за её рамки. Эти функции может реализовывать какой-то софт в портах, или даже в базе - не суть. В общем, как уже не раз говорилось кем-то умным - не готовое блюдо, но качественный полуфабрикат. :) Для одиночной системы, типа личного ноута, имеющегося функционала хватает за глаза. А в массовом, прости меня Мизулина за это слово, продакшене, функционал доп.средств начинает пересекаться с функциями "навороченных" систем управления сервисами в базе. Зачем изобретать то, чем практически не будут пользоваться? :) Во всяком случае, в среде пользователей (читай: разработчиков) OpenBSD.
