находка: обнаружен цикл файловой системы

Когда я пытаюсь найти файл с помощью, find -name "filename"я получаю сообщение об ошибке:

./var/named/chroot/var/named' is part of the same file system loop as `./var/named'

Я выполнил ls -ldi /var/named/chroot/var/named/ /var/namedкоманду и номера инодов совпадают. Исследования показывают, что исправление заключается в удалении жесткой ссылки /var/named/chroot/var/named/с использованием ее rm -fвоссоздания в качестве каталога, но когда я делаю это, мне сообщают, что ее невозможно удалить, поскольку она уже является каталогом. Как я могу это исправить? Я использую Centos 6 с Plesk 11.

Команда mount дает это:

/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/etc/named on /var/named/chroot/etc/named type none (rw,bind)
/var/named on /var/named/chroot/var/named type none (rw,bind)
/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)
/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)
/usr/lib64/bind on /var/named/chroot/usr/lib64/bind type none (rw,bind)
/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)
/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

named, то есть DNS-сервер, работает в chroot. Чтобы получить доступ к файлу конфигурации, скрипт запуска использует его mount --bindдля отображения директории конфигурации внутри chroot. Это означает , что /var/named/такой же , как /var/named/chroot/var/namedи /var/named/chroot/var/named/chroot/var/namedи так далее. Это рекурсивная структура каталогов, поэтому, если findпопытаться преодолеть все это, он никогда не сможет прекратить выполнение, поэтому он понимает, что два каталога на самом деле одинаковы, и выдает вам это сообщение, чтобы предупредить вас.

Сообщение означает, что findне будет искать внутри, /var/named/chroot/var/namedпотому что понял, что это то же самое, что и какой-то другой каталог, уже виденный ранее. Это совершенно безвредно сообщение, вы можете спокойно игнорировать его: после пропуска /var/named/chroot/var/namedна findоперации продолжается в обычном режиме.

Сообщение вызывает код возврата 1 и не может быть проигнорировано, а также не будет работать перенаправление.

Использование findutils findutils-4.4.2-6.el6.x86_64

Кажется, это соответствующий отчет об ошибке:

В системах с ядром Linux «find -printf% F» больше не дает неправильный ответ для файлов в файловых системах, которые были перемонтированы в другом месте с помощью «mount --bind». (Саванна ошибка # 14921).

Решение проблемы безопасности, если вы не можете исправить уязвимый скрипт (т. Е. Потому что он был написан третьей стороной), состоит в удалении пакета bind-chroot, по крайней мере, временно.

Я не думаю, что это жесткая ссылка. Обычно жесткие ссылки на каталог запрещены. Я мог бы быть мягкой ссылкой, но похоже, что это петля монтирования: кажется, что /var/namedили, может быть, /varснова подключена /var/named/chroot. Может быть, это bind mount ( mount -o bind) или просто обычное mount.

Можете ли вы опубликовать вывод вашей mountкоманды? Кроме того, возможно, это крепление необходимо для chroot-тюрьмы, и вам лучше оставить его.

Проблема вызвана скриптом инициализации, namedкоторый монтирует /var/namedкаталог поверх /var/named/chroot. Решение этой проблемы также присутствует в скрипте инициализации.

mount_chroot_conf()
{
   # Mount source is a directory. Mount it only if directory in chroot is
   # empty.

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

1. Стоп named
2. Создать каталог /var/named/chroot/var/named
3. Создайте пустой файл внутри этого каталога
4. Начните named