Por que o / proc não pode ser uma camada de um sistema de arquivos de sobreposição (overlayfs) no linux?

Question

Execute os seguintes comandos no linux (4.4.59 e 4.9.8 são testados) e ele falhará:

mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc

e há uma mensagem de erro em dmesg :

overlayfs: maximum fs stacking depth exceeded

Por que o /proc não pode ser uma camada de um sistema de arquivos de sobreposição?
Se eu substituir /proc por /dev ou /sys , ele será montado sem problema, então parece que há algo especial com /proc .

P.S. O caso de uso está criando um ambiente chroot mais seguro. Quero tornar /dev , /sys e /proc somente leitura em chroot . Existem duas soluções conhecidas:

1. montagem de ligação somente leitura . A limitação é de dois commnads em vez de um requerido.
2. montagem especial somente leitura: mount -t proc -o ro none /tmp/proc . A limitação é submontagem não mapeada automaticamente.

De qualquer forma, ainda estou curioso sobre por que /dev e /sys jogam bem com a sobreposição, mas /proc não.

A pergunta é migrada de stackoverflow .

    

Answer 1

link

    /*
     * procfs isn't actually a stacking filesystem; however, there is
     * too much magic going on inside it to permit stacking things on
     * top of it
     */
s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;

Esta pode não ser uma resposta muito informativa, mas os desenvolvedores do kernel especificamente não suportam isso.

    

Answer 2

Grepping para "profundidade" em /usr/src/linux/fs/overlayfs descobre que é apenas uma simples verificação da profundidade atual de empilhamento em relação a FILESYSTEM_MAX_STACK_DEPTH . Procure por isso nos arquivos de inclusão que o FILESYSTEM_MAX_STACK_DEPTH está definido como 2 em /usr/src/linux/include/linux/fs.h . O comentário diz

Maximum number of layers of fs stack. Needs to be limited to prevent kernel stack overflow

Portanto, aparentemente porque o proc -filesystem adiciona outro nível de indireção comparado a dev ou sys , você excede a profundidade do empilhamento. Eu não vejo nenhuma razão óbvia para que não seja possível empilhar mais, então tente aumentar FILESYSTEM_MAX_STACK_DEPTH , recompile seu kernel e veja se funciona. Isso pode fazer com que o kernel use mais pilha, portanto, mais memória em geral, e isso pode torná-lo mais lento - não sei detalhes sobre a implementação.

Editar em resposta ao comentário

Meu palpite é que o sistema de arquivos proc precisa manter o controle dos arquivos por módulo, para que possa removê-los quando o módulo for removido. Basicamente é um sistema de arquivos de sobreposição para todos os módulos. Mas eu teria que ler a fonte em detalhes para verificar isso (e você pode ler a fonte também :-).

A profundidade do empilhamento está no campo stack_depth da estrutura do superbloco, portanto, para mostrá-lo, você precisa de alguma maneira de acessar as estruturas de dados do kernel. Eu suponho que alguma ferramenta de depuração do kernel poderia fazer isso (ou você sempre pode escrever uma extensão / módulo do kernel que a exibe em algum lugar), mas eu não conheço nenhuma maneira concreta.