¿Aún puede acceder al directorio actual (o directorio raíz) si su usuario no tiene permiso en ese directorio?

Question

Es posible que un programa herede o se le pase un descriptor de archivo abierto; de otro modo, para un archivo no se le permitiría leer (o escribir). Por ejemplo:

(sudo -u nobody echo "hello world") > ~/test-file
(sudo -u nobody cat) < ~/test-file

Pregunta: Si hereda un directorio actual (o directorio raíz) al que su usuario no podría acceder de otro modo, ¿puede acceder a él?

Answer 1

La comparación con los descriptores de archivos es muy engañosa: el directorio actual y raíz de un proceso no son descriptores de archivos ni ningún tipo de puntero a una "descripción de archivo abierto" (a struct file), sino simplemente punteros a entradas de directorio struct dentry.

El kernel no mantiene una descripción de archivo abierto que haga referencia al inodo del directorio señalado por el directorio actual o el directorio raíz, que podría ser heredado por procesos secundarios a través de cualquier tipo de identificador.

Para que puedan usarse de alguna manera, el directorio actual y raíz deben abrirse por ruta, como cualquier otro archivo, y se aplican todas las comprobaciones estándar.

Abrir un archivo con O_PATHdevolverá solo un identificador opaco y se realizará correctamente concualquierarchivo que normalmente no se puede abrir para lectura o escritura, siempre que la ruta sea accesible:

$ perl -e 'sysopen my $fh, "/root", 0, 0 or die "$!"'
Permission denied at -e line 1.
$ perl -e 'sysopen my $fh, "/root", 010000000, 0 or die "$!"' # 010000000 is O_PATH
$

Un fd tan opaco no se puede utilizar como un fd normal ni siquiera mediante procesos privilegiados y, afortunadamente, no hay forma de convertirlo openat(fd, "", AT_EMPTY_PATH|O_RDWR)en dup()un descriptor de archivo normal ;-)

Por cierto, la biblioteca musl.define O_SEARCHcomo O_PATHdesde2012.

Answer 2

No.

# sudo -u nobody ls .
ls: cannot access '.': Permission denied

# sudo -u nobody ls -d .
ls: cannot access '.': Permission denied

# chmod o-rwx /chroot
# chroot --userspec=nobody:nobody /chroot
chroot: failed to run command ‘/bin/bash’: Permission denied

Lo mismo ocurre con el acceso de escritura al directorio actual (o directorio raíz). Si no fuera así, sospecho que sería una fuente de errores de seguridad :-).

Se aplica un comportamiento similar a los descriptores de archivos abiertos O_PATHen Linux.

POSIX (que no define O_PATH) implica que openat(fd, path, ...)funciones similares volverán a verificar el permiso para acceder al directorio abierto fd.a menos que fdse abrió con O_SEARCH. Linux no es compatibleO_SEARCH.