Cuando abres un manual o ves un README que dice “ejecuta chmod 755 sobre el binario”, no están usando magia: están expresando tres grupos de permisos —propietario, grupo, otros— como tres dígitos, donde cada dígito es la suma de valores fijos. Es la forma compacta de decir exactamente qué puede hacer cada quién con un archivo, sin ambigüedad.
El sistema funciona así: cada permiso tiene un valor numérico fijo. Lectura (r) vale 4, escritura (w) vale 2, ejecución (x) vale 1. Para cada grupo de permisos (propietario, grupo, otros), sumas los valores de los permisos que quieres activar. Si quieres rwx, sumas 4+2+1=7. Si quieres rw-, sumas 4+2=6. Si quieres r-x, sumas 4+1=5. Si quieres solo r--, es un 4. Si no quieres dar ningún permiso, es 0. Con eso, un chmod 755 se lee de izquierda a derecha: propietario=7 (rwx), grupo=5 (r-x), otros=5 (r-x).
¿Por qué números y no letras directamente? Porque esta representación es octal (base 8), y cada dígito octal encaja exactamente en 3 bits del modo de archivo que el kernel almacena internamente. No es una convención inventada por comodidad: es el formato nativo del campo mode en el inodo. Cuando ejecutas chmod 644 archivo, el número viaja casi sin transformación hasta la llamada al sistema chmod(2).
Esto lo usas cada vez que tocas permisos en producción: al desplegar un script, al proteger una clave SSH, al dejar que un servidor web sirva ficheros estáticos. La notación octal es más rápida de escribir y menos propensa a errores que la simbólica cuando sabes qué valor quieres desde el principio. Donde sí gana la notación simbólica (chmod +x) es cuando quieres hacer un cambio relativo sin importar el estado actual.
El error clásico es poner chmod 777 como “solución rápida” cuando algo no funciona. Eso significa que cualquier usuario del sistema —y cualquier proceso que corra como ese usuario— puede leer, modificar o ejecutar el archivo. En un servidor compartido, o con cualquier proceso comprometido, eso es una vía de entrada directa. La regla que se aplica en producción sin excepción: permisos mínimos necesarios, nada más.
# Escenario: acabas de crear un script de despliegue, una configuración # con credenciales y una clave SSH. Vamos a asignar los permisos correctos. # Script ejecutable por el propietario; el grupo y otros solo pueden leerlo y ejecutarlo chmod 755 deploy.sh # Comprobamos: el propietario tiene rwx, grupo y otros tienen r-x ls -l deploy.sh # -rwxr-xr-x 1 debian debian 512 jun 10 11:00 deploy.sh # Archivo de configuración con credenciales: el propietario lee y escribe, # nadie más puede ni leerlo chmod 600 config.ini ls -l config.ini # -rw------- 1 debian debian 128 jun 10 11:00 config.ini # Clave privada SSH: mismo criterio que config.ini — si los permisos son # más abiertos, ssh-agent y sshd la rechazan directamente chmod 600 ~/.ssh/id_ed25519 # Archivo de configuración público (sin secretos): el propietario escribe, # el resto solo lee — típico de /etc/nginx/nginx.conf o similar chmod 644 app.conf ls -l app.conf # -rw-r--r-- 1 debian debian 256 jun 10 11:00 app.conf # Un directorio donde el servidor web necesita listar y entrar, # pero no escribir: 755 también es el estándar aquí chmod 755 public_html/ # Esto es lo que NO haces salvo que puedas justificarlo con un argumento # concreto — cualquier usuario del sistema puede leer, modificar y ejecutar chmod 777 public_html/ # red flag inmediato en cualquier revisión de seguridad
Lo que ocurre debajo de cada línea
chmod 755 deploy.sh establece los tres octetos de una vez. El 7 del propietario activa los tres bits de permiso, así que puede leer el script, modificarlo y ejecutarlo. El 5 en grupo y otros activa lectura y ejecución, pero no escritura: cualquiera puede ejecutar el script, pero solo tú puedes cambiarlo. Es el patrón estándar para binarios y directorios que deben ser accesibles de forma pública pero no modificables.
chmod 600 config.ini y chmod 600 ~/.ssh/id_ed25519 usan el mismo valor por la misma razón: el 6 da lectura y escritura al propietario, y los dos ceros eliminan completamente cualquier acceso para el grupo y para otros. OpenSSH es especialmente estricto con esto: si id_ed25519 tiene permisos más permisivos que 600, el cliente SSH imprime Permissions 0644 for '...' are too open y se niega a usarla. No es una advertencia; es un error fatal. El kernel no impone esa restricción, la impone ssh como medida de defensa.
chmod 644 app.conf es el equilibrio típico para configuraciones sin secretos. El propietario puede editar el archivo, pero grupo y otros solo pueden leerlo. Si un proceso del servidor web corre como usuario distinto al propietario del fichero, puede leer la configuración sin necesitar privilegios extra.
El chmod 777 del final merece atención. El problema no es solo que “todo el mundo puede escribir”: en un directorio con 777, cualquier usuario puede borrar o renombrar archivos de otros usuarios dentro de ese directorio, independientemente de los permisos del archivo en sí. En un servidor web, eso significa que un script PHP comprometido puede sobrescribir cualquier otro archivo del directorio. El sticky bit (chmod 1777, como en /tmp) mitiga parte de ese problema para directorios compartidos, pero no lo elimina.
N° 35