O redirecionamento não está realmente ocorrendo dentro de chroot . > /tmp/test é manipulado pelo shell que você está usando. Se você realmente passou > /tmp/test para chroot , ele seria passado para echo e você veria
this is a test > /tmp/test
no seu terminal. Você shell, é claro, não está recebendo chroot ed, por isso é perfeitamente bem com a abertura de /tmp/test . Em seguida, o shell exec s o executável chroot , que chama a chamada de sistema chroot e, em seguida, exec s em echo , que finalmente grava no fd. Por tudo isso, o descritor de arquivo original que seu shell (un chroot ed) abriu nunca é modificado, então o chroot ed echo é capaz de gravar nele.
Este é um recurso deliberado. Um processo fora do chroot tem permissão para abrir arquivos e, em seguida, seus filhos chroot ed podem acessar apenas os arquivos fora do chroot que o processo pai se dignou a passar para eles.
Se você quiser que o redirecionamento ocorra dentro do chroot, você precisa gerar um shell que saiba como interpretá-lo:
chroot $dir bash -c "echo this is a test > /tmp/test"
A ordem das operações é agora: fork (com padrão stdin, stdout e stderr), exec chroot , chroot (agora dentro do chroot), exec bash (sabe como manipular o redirecionamento), fork (detalhes da implementação de bash ), arquivo aberto, exec echo (com nova stdout).