Conocer los ficheros abiertos a lo largo de la vida de un programa es más complicado, sobre todo cuando se manejan muchos y no se tienen abiertos más que por períodos muy cortos. Si un fichero permanece abierto durante todo el programa se puede localizar mediante la interfaz "fd" bajo "/proc", usando el comando "find" nuevamente para localizar el nombre del fichero dado su "inode". En Solaris se puede hacer lo mismo con el comando "pfiles". Algunos de los "fd" abiertos pueden corresponderse a ficheros que no existen realmente, como la entrada y salida estándares, pipes, etc.

Localizar ficheros abiertos apenas un instante es bastante más complejo. Lo normal en estos casos consiste en ejecutar el programa trazando las llamadas al sistema que realiza, entre ellas llamadas tales como "open". En Solaris se dispone de una utilidad sencilla llamada "truss" que las llamadas al sistema por parte de un proceso. Bajo Linux no conozco una utilidad así, aunque es sencillo ejecutar el proceso con el GDB (GNU Debugger) y poner un punto de ruptura a la entrada del "open".

Una vez que sabemos qué librerías, ficheros y dispositivos necesita un proceso podemos replicarlos dentro de la nueva estructura "chroot", ya sea copiándolos o bien creando un enlace "hard". Recordad que un enlace simbólico no sirve.

¿Cómo de seguro es un entorno "chroot"?. La respuesta no es sencilla. Bien configurado, un confinamiento de este tipo es muy útil, pero en la práctica una máquina en producción tiene tantos procesos abiertos y las interrelaciones entre los mismos es tan compleja que asegurarlo es muy difícil. En realidad nuestra obligación es construir toda una serie de barreras anti-intrusiones, como un tamiz. En ese sentido el "chroot" es una herramienta más, y muy útil. Debemos ser conscientes, sin embargo, de sus limitaciones; su misión consiste en confinar el sistema de ficheros, no en proporcionar una auténtica máquina virtual absolutamente segura.