Та там хората са го написали хипер ясно:
***
*pid-file*
The pathname of the file the server writes its process ID in. If not
specified, the default is /var/run/named.pid. The pid-file is used
by programs that want to send signals to the running name server.
Specifying *pid-file none* disables the use of a PID file — no file
will be written and any existing one will be removed. Note that
*none* is a keyword, not a file name, and therefore is not enclosed
in double quotes.
***
Тази декларация се подава в структурата options на конфигурационния
файл named.conf. Тя може да отмени компилационно зададения път до
pid файла.
Какво значи това в контекста на chroot? Това значи, че ако в
named.conf се направи декларация от вида:
options {
...
pid-file "/var/run/bind/run/named.pid";
...
};
то ако chroot директорията е /var/named/chroot, то pid файла ще е
/var/named/chroot/var/run/bind/run/named.pid.
Т.е. правиш в chroot директорията следното:
# cd /var/named/chroot
# mkdir -p var/run/bind/run
после правиш създадената с втория ред писаема за потребителя, с
чиито права се изпълняват процесите на демона named.
Аз бях силно потресен от това, което видях в първото писмо, дало
началото на нишката "Bind в chroot". В един от редовете от syslog
журнала съзрях следния ужас:
Mar 18 09:35:26 localhost named[11017]: starting BIND 9.2.5 -u
nobody -t /var/lib/named
Процесите на демона named се пускат със собственик потребителя nobody,
който почти сигурно се ползва за какво ли още не. Ако утре се пусне
демон с правата на nobody и той бъде пробит, какво ли ще се случи при
добро желание от страна на атакуващия с процесите на named, чиито
процеси също са собственост на потребителя nobody? Например, как ви
звучи "обезобразяване на зонален файл":) apt-get не прави запис за нов
потребител, с който да се пуска named. Но поне го направете ръчно за
да няма проблеми. Ето пример за такъв потребител:
Можете да се сърдите, но Debian не предоставя възможностите нужни за
работа в chroot среда на демона named. Изобщо в тази дистрибуция
малко са скарани с темата "сигурност" (особено след като вчера след
apt-get install ntp-server разбрах, че ntpd се пуска с права на root
:), което ме разтрепера и накара да преправям init скрипта, защото в
този init скрипт нямаше дори предвидено четене на
/etc/defaults/ntp-server, от където евентуално да се зададе кой да е
собственик на процесите, за опционлано заключване изобщо не може и
да се говори).
Конкретно за bind:
1) в /etc/init.d/bind9 липсва каквато и да е мобилност и оперативност
за заключване на демона named
конкретно:
- start () {
echo -n "Starting domain name service: named"
if [ ! -x /usr/sbin/named ]; then
echo "named binary missing - not starting"
exit 1
fi
start-stop-daemon --start --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named --
$OPTIONS
echo "."
Прекрасно, но тук се обвързваш с pid файл, който не е в chroot, дори в
$OPTIONS да имаш указване за chroot директория с "-t".
- stop () {
echo -n "Stopping domain name service: named"
# --exec doesn't catch daemons running deleted instances of
named,
# as in an upgrade. Fortunately, --pidfile is only going
to hit
# things from the pidfile.
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --name named
echo "."
}
Отново това обвързване. Да не говорим, че ISC пишат в документацията
си, но кой да чете. Демонът named се спира с командата:
# rndc stop
Ето как изглежда stop функцията в bash скрипт в друга дистрибуция
(където няма проблеми с chroot пускането на named):
stop() {
# Stop daemons.
echo -n $"Stopping $prog: "
/usr/sbin/rndc stop >/dev/null 2>&1
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || {
# killproc named
# Never do this! Can cause corrupt zone files!
/usr/sbin/rndc stop >/dev/null 2>&1
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named
echo
return $RETVAL
}
success
echo
return $RETVAL
}
Никакви обвързвания с pid и оттам никакви проблеми с chroot. Няма
проблеми със спирането. Може дори да не се използва pid файл.
Поздрави
Весо
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara
Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================