Bind mount - resultados diferentes no CentOS 6 e no CentOS 7

Question

Estou montando alguns diretórios (bind mount) em um ambiente chroot, mas eles se comportam de maneira diferente no CentOS 6 e 7 - exatamente os mesmos comandos.

Exemplo:

Eu tenho meu chroot env em /chroot/base .

Depois eu montei em todos os usuários:

mount --bind /chroot/base /chroot/$user

Em seguida, montei /home/$user no chroot do mesmo usuário:

mount --bind /home/$user /chroot/$user/home/$user

No CentOS 6 ele funciona bem e monta exatamente esses diretórios, mas no CentOS 7 eu recebo algo assim:

/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

O homedir de cada usuário é montado no chroot env dos outros usuários.

Por que isso está acontecendo? O que mudou entre CentOS6 / 7 que poderia estar causando isso?

Editar:

Executando ls na pasta para user1 , por exemplo ( 123user1 é um arquivo touch /home/user1/123user1 simples):

root@server:~# ls /chroot/user1/home/user1/
123user1
root@server:~# ls /chroot/user2/home/user1/
123user1
root@server:~# ls /chroot/user3/home/user1/
123user1

Ainda mais estranho é isso:

root@server:~# ls /chroot/base/home/user1/
123user1

Eu não montei isso em nenhum estágio

    

Answer 1

A origem do comportamento parece o padrão alterado da operação de subárvores compartilhadas . A documentação do kernel Documentation / sharedsubtree.txt menciona que private é o padrão, enquanto na verdade é shared , que pode ser obtido visualizando /proc/self/mountinfo após montar um diretório com --bind . / p>

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

Isso causa a propagação de montagens sob / chroot / test de volta para / chroot / base que afeta as outras montagens de bind derivadas de / chroot / base .

Para recuperar o comportamento antigo, é necessário especificar --make-private explicitamente ou private como opção de montagem em / 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

Acho que é melhor aplicar a opção private a qualquer montagem de bind que você queira que o comportamento antigo volte.

Atualizar

O padrão do kernel ainda é private , mas systemd está remontando os sistemas de arquivos como shared devido ao melhor suporte ao contêiner. Do site do github do systemd :

Mark the root directory as shared in regards to mount propagation. The kernel defaults to "private", but we think it makes more sense to have a default of "shared" so that nspawn and the container tools work out of the box. If specific setups need other settings they can reset the propagation mode to private if needed. Note that we set this only when we are invoked directly by the kernel. If we are invoked by a container manager we assume the container manager knows what it is doing (for example, because it set up some directories with different propagation modes).