CHROOT, en sus dos modos (comando shell y llamada al sistema), sólo puede ser invocado por el superusuario del sistema (root), lo cual es bastante lógico dado el poder que supone. Ya que un CHROOT cambia la raíz del sistema de ficheros, los procesos lanzados no pueden ampliar sus privilegios, ya que el nuevo estará contenido en el antiguo. Ni siquiera el superusuario puede invertir eso... en teoría.

El CHROOT funciona con los ficheros que se manejen a continuación, pero cualquier descriptor de fichero activo seguirá funcionando. En otras palabras, si abrimos un fichero y hacemos un CHROOT que lo deje fuera, seguiremos pudiendo acceder a él a través del descriptor abierto. Ello resulta útil, por ejemplo, para hacer que los logs de un servidor en CHROOT se almacenen fuera de su alcance. Es, no obstante, un punto al que prestar atención para no dejar abierta alguna puerta de forma inadvertida.

También hay que recordar que no podremos acceder a nada fuera del CHROOT. Eso incluye comandos shell y librerías dinámicas/compartidas. Habrá que replicar los comandos y librerías necesarias dentro del CHROOT. Se pueden copiar o bien, ocupando menos sitio, hacerles un enlace "duro". Un enlace simbólico no funciona porque el fichero original no estará disponible.

En algunos casos, dependiendo del sistema, será necesario incluso replicar algunos dispositivos "/dev". Eso es lo que ocurre, por ejemplo, en Solaris si queremos que los servidores corriendo en el nuevo entorno tengan acceso a la red.

La relación entre el CHROOT y algunos demonios del sistema, como el SYSLOG, es bastante... bueno, digamos que "truculenta" :-). Es cuestión de probar en cada caso.