Я монтирую пару каталогов (bind mount) в среде chroot, но они ведут себя по-разному в CentOS 6 и 7 - точно такие же команды.
Пример:
У меня chroot env в /chroot/base.
Затем монтирую его на каждого пользователя:
mount --bind /chroot/base /chroot/$user
Затем я поднимаюсь /home/$user в chroot того же пользователя:
mount --bind /home/$user /chroot/$user/home/$user
На CentOS 6 он работает нормально и монтирует именно эти каталоги, но на CentOS 7 я получаю что-то вроде этого:
/dev/mapper/cl_cp-home /chroot/user1/home/user1 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user2/home/user1 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user3/home/user1 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user2/home/user2 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user3/home/user2 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user1/home/user2 xfs rw,relatime,attr2,inode64,usrquota 0 0
/dev/mapper/cl_cp-home /chroot/user3/home/user3 xfs rw,relatime,attr2,inode64,usrquota 0 0
Homedir каждого пользователя монтируется в chroot env других пользователей.
Почему это происходит? Что изменилось в CentOS6 / 7, что могло быть причиной этого?
Редактировать:
Бег ls в папке для user1 например (123user1 это простой touch /home/user1/123user1 файл):
root@server:~# ls /chroot/user1/home/user1/
123user1
root@server:~# ls /chroot/user2/home/user1/
123user1
root@server:~# ls /chroot/user3/home/user1/
123user1
Еще более странно это:
root@server:~# ls /chroot/base/home/user1/
123user1
Я не монтировал это на любом этапе
Источник поведения кажется измененным по умолчанию для операция общих поддеревьев. Документация ядра Документация / sharedsubtree.txt упоминает, что private по умолчанию, тогда как на самом деле это shared которые можно получить, просмотрев /proc/self/mountinfo после монтирования каталога с --bind.
root@localhost ~]# mount --bind /chroot/base /chroot/test
[root@localhost ~]# grep test /proc/self/mountinfo
234 62 253:1 /chroot/base /chroot/test rw,relatime shared:1 - xfs /dev/vda1 rw,attr2,inode64,noquota
Это вызывает распространение креплений под / chroot / test вернуться к / chroot / base который затем влияет на другие крепления, производные от / chroot / base.
Чтобы вернуться к прежнему поведению, нужно указать --make-private явно или private как вариант монтирования в / etc / fstab.
[root@localhost ~]# umount /chroot/test
[root@localhost ~]# mount --bind --make-private /chroot/base /chroot/test
[root@localhost ~]# grep test /proc/self/mountinfo
234 62 253:1 /chroot/base /chroot/test rw,relatime - xfs /dev/vda1 rw,attr2,inode64,noquota
Я думаю, что лучше применить private вариант для любого крепления, которое вы хотите старый поведение назад.
По умолчанию ядро по-прежнему private но systemd перемонтирует файловые системы как shared за счет лучшей поддержки контейнера. Из systemd github сайт:
Отметьте корневой каталог как общий для распространения монтирования. По умолчанию ядро имеет значение «частное», но мы думаем, что имеет смысл использовать значение по умолчанию «общий», чтобы nspawn и инструменты контейнера работали из коробки. Если для определенных настроек требуются другие настройки, они могут сбросить режим распространения до частного, если это необходимо. Обратите внимание, что мы устанавливаем это только тогда, когда нас вызывает непосредственно ядро. Если нас вызывает диспетчер контейнеров, мы предполагаем, что диспетчер контейнеров знает, что он делает (например, потому что он настроил некоторые каталоги с разными режимами распространения).