Calculadora de Permisos chmod

Qué hace esta herramienta

Traduce permisos de archivos de Linux, macOS y cualquier sistema POSIX entre las tres formas en que se escriben: casillas, octal (755) y la notación de ls -l (rwxr-xr-x). Cambia cualquiera de las tres y las otras dos se ajustan solas, y abajo tienes el comando chmod listo para copiar.

Además cubre dos cosas que casi ninguna calculadora online incluye y que son justo donde se falla: los bits especiales (setuid, setgid, sticky) y una calculadora de umask que aplica la máscara de verdad en lugar de restar.

Cómo usarla

1. Marca las casillas, o escribe directamente el valor en el campo octal.
2. El campo octal acepta 755, 0755, 4755 y también rwxr-xr-x o la línea entera que escupe ls -l.
3. Copia el comando que necesites: numérico, simbólico o recursivo.

Cómo se leen los permisos

Un permiso POSIX responde a dos preguntas: quién y qué puede hacer.

Los define POSIX, así que valen igual en Linux, macOS y BSD. El quién son tres grupos, en este orden: el propietario del archivo, el grupo al que pertenece, y todos los demás. El qué son tres permisos, y cada uno vale un número:

Se suman los valores dentro de cada grupo y sale un dígito del 0 al 7. Tres grupos, tres dígitos:

• 755 = propietario 7 (4+2+1, todo), grupo 5 (4+1), otros 5 (4+1) → rwxr-xr-x
• 644 = propietario 6 (4+2), grupo 4, otros 4 → rw-r--r--
• 600 = propietario 6, nadie más nada → rw-------

755 y 644, y por qué son los dos valores que más se usan

La diferencia entre ambos es únicamente el bit de ejecución, y la regla en un servidor web es corta:

• 644 para archivos. Un .html, un .php, una imagen o un .css no necesitan ejecutarse. El servidor los lee y los sirve.
• 755 para directorios. Un directorio sí necesita el bit x, pero no por lo que parece.

La trampa de la x en un directorio

Este es el punto donde se pierde más tiempo, y merece la pena tenerlo claro porque explica la mayoría de los 403 “imposibles”.

En un archivo, x significa ejecutar: puedes lanzarlo como programa.

En un directorio, x significa atravesar: puedes entrar y llegar a lo que hay dentro. No tiene nada que ver con ejecutar nada.

Las consecuencias son poco intuitivas:

• Directorio con r pero sin x: puedes listar los nombres de los archivos, pero no puedes abrir ninguno. ls funciona, cat falla.
• Directorio con x pero sin r: no puedes listar el contenido, pero sí puedes abrir un archivo si sabes su nombre exacto. Es la base del truco de los directorios “ocultos pero accesibles”.
• Y el x hace falta en todos los directorios del camino. Si /var/www/html/ está bien pero /var/www/ no tiene x para el usuario del servidor, nada de dentro se sirve.

Cuando un archivo tiene permisos correctos y aun así devuelve 403, el problema casi siempre está en un directorio padre, no en el archivo.

Los bits especiales

Delante del octal cabe un cuarto dígito para tres bits que cambian el comportamiento:

Dónde aparecen de verdad:

• 1777 es /tmp. Todo el mundo escribe, pero nadie borra los archivos de otro. Sin el sticky bit, /tmp sería un desastre.
• 2775 en una carpeta de equipo hace que los archivos nuevos hereden el grupo del proyecto, en lugar del grupo primario de quien los crea. Es la forma correcta de montar un directorio compartido.
• setuid conviene evitarlo. Un binario con setuid perteneciente a root que tenga cualquier fallo es una escalada de privilegios directa. Es de las primeras cosas que busca un atacante con find / -perm -4000.

Cómo se ven en ls

Los bits especiales no tienen columna propia: pisan la x del grupo correspondiente. Y el detalle que despista es que la letra cambia de caja según si la x que tapan estaba puesta o no:

• rwsr-xr-x → setuid con ejecución (4755)
• rwSr-xr-x → setuid sin ejecución (4655), la S mayúscula avisa de que el bit está pero no sirve de nada
• rwxrwxrwt → sticky con ejecución (1777)
• rwxrwxrwT → sticky sin ejecución (1776)

Una letra mayúscula ahí casi siempre significa que alguien puso el bit especial y se olvidó del de ejecución.

La umask, que no es una resta

La umask decide con qué permisos nace un archivo nuevo. La explicación que circula por todas partes es “se resta a 666 o a 777”, y funciona lo justo para que nadie la corrija.

Lo que hace de verdad es aplicarse como máscara de bits que quita permisos:

resultado = base AND NOT umask

Y la base no es la misma para todo:

• Los archivos se piden con 666. El sistema nunca concede x a un archivo por su cuenta, precisamente para que un archivo descargado no nazca ejecutable.
• Los directorios se piden con 777, porque sin x no se podrían atravesar.

Con la umask 022, que es la habitual: un archivo nace 644 y un directorio 755 — exactamente los dos valores de la regla del servidor web.

Dónde se nota la diferencia entre restar y enmascarar: con umask 013, restar daría 666 - 013 = 653. La máscara real da 664. El 1 de la umask quita el bit de ejecución, que la base 666 no tenía, así que no quita nada; restar sí lo descuenta y da un número que no existe.

Errores frecuentes

• chmod 777 para “arreglarlo”. Si algo solo funciona con 777, el problema es de propietario, no de permisos. Lo correcto es chown al usuario del servidor web y dejar 644/755.
• chmod -R 755 sobre todo el proyecto. Deja todos los archivos ejecutables, incluidos los .env y las claves. Lo habitual es aplicar 755 solo a directorios y 644 a archivos, que se hace con find . -type d -exec chmod 755 {} + y find . -type f -exec chmod 644 {} +.
• Claves SSH con permisos abiertos. ssh se niega a usar una clave privada que puedan leer otros. Tiene que ser 600.
• Confundir permisos con propiedad. chmod cambia qué se puede hacer; chown cambia quién es el dueño. Muchos problemas que parecen de permisos se resuelven con el segundo.