Cada archivo y directorio en Linux lleva pegado un pequeño conjunto de metadatos que el kernel consulta cada vez que alguien intenta leerlo, modificarlo o ejecutarlo. Eso es el modelo de permisos Unix: nueve bits organizados en tres categorías de tres bits cada una, más la identidad de quién posee el archivo y a qué grupo pertenece.
El diseño viene de los años 70 en Bell Labs y responde a una pregunta concreta: ¿cómo controlas el acceso cuando varias personas comparten la misma máquina? La respuesta fue simple y efectiva. Cada inodo —la estructura interna que representa un archivo en el sistema de ficheros— almacena dos identificadores de propiedad: el owner (usuario propietario, uid) y el grupo propietario (gid). Cuando un proceso intenta acceder al archivo, el kernel hace exactamente tres comprobaciones en orden: ¿es el proceso el owner? ¿Pertenece el proceso al grupo propietario? Si no es ninguna de las dos cosas, cae en la categoría other.
El momento de usar este conocimiento es ahora mismo y siempre: cada vez que un script no arranca, un servidor web no puede leer su configuración, o un usuario no puede entrar a un directorio, el problema casi con certeza está aquí. Si lo entiendes mal, las consecuencias van desde servicios caídos hasta agujeros de seguridad —exponer archivos sensibles a other porque pensabas que group era suficiente, o bloquear a tu propio usuario de una carpeta con un chmod mal aplicado.
La parte que más confunde al principio es que los bits rwx significan cosas distintas según el tipo de objeto. Para un archivo regular:
r— puedes leer su contenido (cat,less,cp…)w— puedes modificar su contenidox— puedes ejecutarlo como programa
Para un directorio, el significado cambia por completo:
r— puedes listar las entradas que contiene (ls)w— puedes crear o borrar entradas dentro de él (ficheros, subdirectorios)x— puedes entrar al directorio (cd) y acceder a lo que hay dentro
Fíjate en la trampa de w en directorios: controla las entradas del directorio, no los archivos en sí. Una entrada de directorio es básicamente el nombre del archivo y el número de inodo al que apunta. Crear un archivo nuevo es añadir una entrada; borrar un archivo es eliminar esa entrada. El permiso w del archivo en sí no interviene para nada en el borrado —lo que manda es el w del directorio que lo contiene. Si tienes w en un directorio pero no en un archivo que hay dentro, puedes borrar ese archivo sin problema. Al revés —w en el archivo pero no en el directorio padre— no puedes borrarlo, aunque sí puedes modificar su contenido.
Ejemplo completo
# Creamos un directorio de trabajo para la demostración mkdir /tmp/demo_permisos cd /tmp/demo_permisos # Creamos un archivo de texto y un script de shell echo "datos confidenciales" > informe.txt printf '#!/bin/sh\necho "Hola desde script"\n' > saludo.sh # Ver el estado inicial de los permisos ls -l # El resultado muestra algo así: # -rw-r--r-- 1 alice alice 21 jun 1 10:00 informe.txt # -rw-r--r-- 1 alice alice 35 jun 1 10:00 saludo.sh # # Formato: [tipo][owner][group][other] # El guión inicial (-) indica archivo regular; una d indicaría directorio # Damos permiso de ejecución al script SOLO para el owner chmod u+x saludo.sh # Quitamos la lectura a 'other' en el informe (contiene datos sensibles) chmod o-r informe.txt # Verificamos el resultado ls -l # Ahora deberías ver: # -rw-r----- 1 alice alice 21 jun 1 10:00 informe.txt # ^^^ owner puede leer y escribir; group puede leer; other: nada # -rwxr--r-- 1 alice alice 35 jun 1 10:00 saludo.sh # ^^^ owner puede leer, escribir y ejecutar; los demás solo leer # Ejecutamos el script para confirmar que funciona ./saludo.sh # Ahora vamos a ver la diferencia entre w en archivo vs w en directorio mkdir caja echo "archivo dentro" > caja/dentro.txt chmod 444 caja/dentro.txt # solo lectura para todos en el archivo chmod 755 caja # owner tiene rwx; los demás rx (sin w) # Como owner del directorio caja, podemos borrar dentro.txt # aunque el archivo en sí sea solo lectura (444): rm caja/dentro.txt # funciona: tenemos w en el directorio 'caja' # Recreamos el archivo y demostramos el caso contrario: echo "de nuevo" > caja/nuevo.txt chmod 200 caja # solo w para owner, sin r ni x — directorio casi inútil ls caja # falla: sin x en el directorio no puedes acceder a su contenido # ls: cannot access 'caja': Permission denied (o similar) cd caja # también falla por la misma razón # Restauramos x para poder operar con normalidad chmod 755 caja
Lo que está pasando debajo
Cuando ejecutas ls -l, la primera columna es la cadena de diez caracteres que codifica el tipo y los nueve bits de permisos. El primer carácter es el tipo (- para archivo regular, d para directorio, l para enlace simbólico). Los nueve siguientes son tres grupos de tres: los primeros tres son los permisos del owner (u), los tres del medio son los del grupo (g), y los últimos tres son los de other (o).
La notación chmod u+x saludo.sh usa la forma simbólica: u es el owner, + significa añadir, x es el bit de ejecución. Esta forma es más segura cuando estás haciendo cambios quirúrgicos porque no toca los bits que no mencionas. La alternativa octal —chmod 755— establece los nueve bits de golpe: 7 es rwx (4+2+1), 5 es r-x (4+0+1), 0 es ---. Útil cuando quieres establecer el estado completo desde cero.
El experimento con caja/dentro.txt ilustra exactamente por qué chmod 444 en un archivo no lo protege del borrado. Cuando haces rm, el kernel no mira los permisos del inodo del archivo; mira si tienes w en el directorio padre para poder eliminar la entrada que apunta a ese inodo. Es por eso que en sistemas multiusuario, si quieres que nadie borre un archivo, tienes que restringir el w del directorio que lo contiene, no solo el archivo en sí.
El caso de chmod 200 caja muestra que x en un directorio es la llave de entrada. Sin ese bit, no puedes hacer cd dentro, no puedes resolver rutas que pasen por él, y ls no puede leer el contenido aunque teóricamente tengas r. En la práctica, r sin x en un directorio es casi inútil —puedes obtener la lista de nombres, pero no puedes acceder a ninguno de los archivos porque acceder implica atravesar el directorio.
N° 33