Cómo funcionan los permisos de archivo en Unix: leer 755 sin adivinar

Tres dígitos, tres partes, y solo una se aplica

En la salida de `ls -l` el primer carácter indica el tipo — un guion para un archivo normal, d para un directorio, l para un enlace simbólico — y los nueve siguientes son tres grupos de tres: propietario, grupo, otros. Lo que sorprende es que no se acumulan. El núcleo escoge la primera clase a la que perteneces y se detiene ahí. Si eres el propietario de un archivo en 477 obtienes r-- y nada más, aunque los bits de grupo y otros estén abiertos de par en par: la clase propietario coincidió primero y el resto no se consulta nunca.

Hay dos formas de escribir un cambio y no son equivalentes. El octal es absoluto: `chmod 644 notes.txt` fija el modo entero y borra lo que hubiera antes. El simbólico es relativo: `chmod u+x script.sh` añade un bit y deja los otros ocho intactos. En un script de despliegue casi siempre quieres la forma octal, porque produce el mismo estado final sea cual sea el aspecto del archivo al llegar.

En un directorio, el bit de ejecución es un derecho completamente distinto

Nada se ejecuta nunca por dar el bit x a un directorio. En un directorio ese bit es permiso de búsqueda: deja que un proceso resuelva un nombre dentro y alcance lo que hay detrás. La separación se ve fácil. Pon un directorio en 400 y `ls` imprimirá encantado los nombres que contiene, pero cada consulta falla y `cat dir/archivo` se rechaza: ves las etiquetas y no tocas nada. Ponlo en 100 y ocurre lo contrario: no puedes listar nada, pero si ya conoces la ruta exacta abres el archivo. Esa asimetría explica que un directorio personal en 711 funcione: otros alcanzan ~/public_html sin poder enumerar el resto.

La misma lógica explica un resultado que parece un fallo. Borrar un archivo no es una modificación del archivo: es una modificación del directorio que lo lista. Así que el permiso que decide si un archivo puede eliminarse es escritura más ejecución sobre el directorio que lo contiene, y el modo del propio archivo es irrelevante. Un archivo en 444 dentro de un directorio en 777 puede borrarlo cualquiera de la máquina. Ese es justo el agujero que el sticky bit vino a tapar, y por eso /tmp es 1777 y no 0777.

El cuarto dígito y por qué umask no es un permiso

Tres bits especiales viven en un dígito inicial opcional. Setuid es 4000: en un binario ejecutable lo hace correr con la identidad del propietario, que es como passwd edita un archivo que tú no puedes. En Linux se ignora en silencio en los scripts interpretados y no significa nada en un directorio. Setgid es 2000: en un binario hace lo mismo con el grupo, y en un directorio hace algo mucho más útil — las entradas nuevas heredan el grupo del directorio en vez del de quien las crea, y los subdirectorios nuevos heredan también el bit setgid, que es la forma estándar de mantener coherente un árbol de proyecto compartido. El sticky es 1000: en un directorio limita borrar y renombrar una entrada al propietario de la entrada, al del directorio o a root.

El umask es la pieza que más se invierte. No es el permiso que reciben los archivos nuevos: es una máscara de bits que se quitan de lo que pidió el programa que los crea. Los programas piden 666 para un archivo y 777 para un directorio, y cada bit puesto en el umask se apaga. Con el umask habitual 022 obtienes por tanto 644 para archivos y 755 para directorios. Y borra en vez de restar: umask 023 sigue dando 644 en un archivo nuevo, no 643, porque el archivo nunca pidió el bit de ejecución y no hay nada que quitar. Un pariente cercano: `chmod +x` sin letra de clase no equivale a `chmod a+x`, porque la forma escueta también respeta tu umask — bajo umask 077 concede la ejecución solo al propietario.

Preguntas frecuentes

¿Por qué chmod 777 es la solución equivocada?

Da acceso de escritura a todas las cuentas de la máquina, incluida la identidad bajo la que corre tu servidor web o un proceso comprometido, y el código escribible por todos es código que cualquiera puede sustituir. Además suele errar la causa real, que más a menudo es una propiedad equivocada o un bit de ejecución ausente en un directorio padre que un permiso demasiado estrecho. Algunos programas se niegan de plano: OpenSSH ignora una clave privada o un authorized_keys escribible por el grupo o por todos.

¿chmod 755 hace que un script se pueda ejecutar?

Concede permiso para intentarlo, que no es lo mismo que hacer que funcione. Un archivo de texto necesita además una línea shebang que nombre un intérprete existente, o el núcleo no tiene a quién entregárselo. Otras dos cosas se imponen por completo sobre el modo: un sistema de archivos montado con la opción noexec se niega a ejecutar nada, digan lo que digan los bits, y cada directorio del camino hasta el archivo necesita su propio bit de ejecución para que el archivo sea siquiera alcanzable.

¿Por qué alguien puede borrar un archivo que puse en solo lectura?

Porque el borrado es un cambio en el directorio, no en el archivo. El núcleo comprueba escritura y ejecución sobre el directorio que guarda el nombre y nunca mira el modo del archivo. Para impedirlo, estrecha el directorio o ponle el sticky bit, que limita borrar y renombrar al propietario de la entrada, al del directorio y a root — la razón de que un /tmp compartido sea 1777.