chmod 755 vs rwxr-xr-x: Domina los Permisos Unix de una Vez

El comando que todos hemos abusado

La escena es conocida: algo falla con permisos, llevas veinte minutos depurando, te cansas, escribes chmod 777 y funciona. Problema resuelto. Excepto que acabas de dar permiso total de lectura, escritura y ejecución a cualquier usuario del sistema, y lo que era un problema de configuración ahora es un agujero de seguridad.

Los permisos de Unix son de esas cosas que parecen complicadas hasta que encajan, y entonces resultan elegantes. Este tutorial va de eso: de entender el modelo de verdad, para no volver a necesitar el 777 nunca más.

---

El modelo en treinta segundos

Cada archivo y directorio en Unix tiene tres grupos de permisos aplicados en orden:

1. Owner (u): el usuario dueño del archivo
2. Group (g): el grupo al que pertenece el archivo
3. Others (o): todo el resto del mundo

Y cada grupo puede tener hasta tres permisos:

• r (read, 4): leer el contenido
• w (write, 2): modificarlo
• x (execute, 1): ejecutarlo

Cuando haces ls -l ves algo así:

-rwxr-xr-- 1 ana developers 4096 nov  3 10:22 deploy.sh
│└┬┘└┬┘└┬┘
│ │   │   └── others: r-- → solo pueden leer
│ │   └────── group: r-x  → leer y ejecutar
│ └────────── owner: rwx  → todo
└───────────── tipo: - archivo (d sería directorio)

El orden importa: el sistema comprueba primero si eres el owner, luego si estás en el grupo, y solo entonces mira "others". Si eres el owner y no tienes r, no puedes leer el archivo aunque others sí pueda. Suena raro, pero es así: los permisos se evalúan en cascada y se detienen en la primera coincidencia.

---

La trampa de los directorios

Aquí es donde casi todo el mundo se confunde la primera vez. En un directorio, los mismos tres permisos significan cosas distintas:

• r: puedes listar los nombres de los archivos que contiene
• x: puedes entrar en él (cd) y acceder a los archivos cuyo nombre conoces
• w: puedes crear y borrar archivos dentro (¡incluido borrar archivos de otros!)

Las combinaciones raras son las divertidas: un directorio con --x pero sin r te permite acceder a /secreto/archivo.txt si sabes que existe, pero no puedes hacer ls para descubrirlo. Es la base de los directorios "semiocultos" tipo ~/Public en sistemas multiusuario.

Y ojo al dato peligroso: borrar un archivo depende del permiso w del directorio, no del archivo. Un archivo de solo lectura dentro de un directorio escribible se puede borrar igualmente. Por eso existe el sticky bit, que veremos luego.

---

El sistema octal: suma y listo

Cada triplete rwx es un número en binario donde r vale 4, w vale 2 y x vale 1. Suma lo que quieras:

rwx = 4+2+1 = 7
rw- = 4+2+0 = 6
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
--- = 0+0+0 = 0

Tres dígitos = owner, group, others. Los que usarás el 95% del tiempo:

chmod 644 archivo.txt    # rw-r--r-- : archivos normales, el default sensato
chmod 755 script.sh      # rwxr-xr-x : scripts y programas ejecutables
chmod 600 ~/.ssh/id_ed25519  # rw------- : claves privadas, nadie más toca esto
chmod 700 ~/.ssh         # rwx------ : el directorio ssh completo
chmod 400 backup.key     # r-------- : ni tú puedes modificarlo por accidente

¿Y si necesitas la combinación rara? Puedes calcularla de cabeza (¿rw-r-x-wx? = 653) o usar nuestra calculadora chmod, que traduce en ambos sentidos: marcas las casillas y te da el octal, o escribes el número y ves la notación simbólica.

---

La notación simbólica: cuando el octal estorba

El octal es genial cuando reescribes los permisos por completo. Pero muchas veces solo quieres cambiar una cosa sin tocar el resto. Ahí gana la forma simbólica:

chmod u+x script.sh       # añade ejecución al owner, lo demás igual
chmod go-w config/        # quita escritura a group y others
chmod o-rwx secreto.key   # others no ve absolutamente nada
chmod a=r publico.txt     # todos exactamente lectura (a = all)
chmod u=rw,g=r,o= data.db # combina varias asignaciones

La sintaxis es [quién][operación][permiso]: quién es u, g, o o a; operación es + (añadir), - (quitar) o = (fijar exactamente); y permiso es cualquier combinación de rwx.

Hay una joya escondida: la X mayúscula. chmod -R u+rwX,go+rX,go-w proyecto/ da ejecución solo a directorios y a archivos que ya eran ejecutables. Es la forma correcta de arreglar permisos recursivamente sin convertir todos tus .txt en "ejecutables" de mentira.

---

Los bits especiales: el cuarto dígito que nadie usa

Antes del famoso triplete hay un dígito opcional con tres flags: setuid (4), setgid (2) y sticky (1). Así que chmod 4755 no es un typo: es "setuid + rwxr-xr-x".

setuid: ejecutar como el dueño

Un ejecutable con setuid corre con los permisos de su dueño, no de quien lo lanza. El ejemplo canónico:

-rwsr-xr-x 1 root root /usr/bin/passwd

Esa s donde debería ir la x del owner es setuid: passwd te deja modificar /etc/shadow, que pertenece a root, porque el proceso corre como root mientras dura el cambio. Es poderoso y por eso mismo es una fuente histórica de escaladas de privilegio — si un script tuyo con setuid tiene un bug, el atacante corre como tu usuario (o peor, como root).

setgid: el truco de los directorios compartidos

En ejecutables hace lo mismo con el grupo. Pero su uso realmente útil es otro: en un directorio, setgid hace que los archivos creados dentro hereden el grupo del directorio en lugar del grupo primario del creador.

chmod 2770 /srv/equipo    # rwxrws--- : todo lo creado aquí es del grupo "equipo"

Si mantienes un directorio compartido entre varios desarrolladores, esto te ahorra el clásico "creé el archivo con mi grupo y ahora nadie puede editarlo".

sticky bit: el guardián de /tmp

En un directorio con sticky bit, cada usuario solo puede borrar o renombrar sus propios archivos, aunque el directorio sea escribible por todos. Es lo que hace seguro a /tmp:

drwxrwxrwt 17 root root /tmp
chmod 1777 /tmp   # sticky + permisos abiertos

Sin sticky bit, /tmp sería un caos donde cualquiera borra los archivos de cualquiera. Con sticky bit (esa t final), solo el dueño de cada archivo puede eliminarlo. Cuando veas una T mayúscula en lugar de t, significa que el bit está puesto pero el permiso x no — señal de que algo está mal configurado.

---

umask: de dónde salen los permisos por defecto

Cuando creas un archivo y no le pones permisos, el sistema aplica tu umask: una máscara de bits que quita permisos de los máximos por defecto (666 para archivos, 777 para directorios).

umask           # típicamente 022
# archivos nuevos: 666 - 022 = 644
# directorios:     777 - 022 = 755

umask 077       # modo paranoico: solo tú ves lo que creas
# archivos nuevos: 600, directorios: 700

Si alguna vez te preguntaste por qué tus archivos salen siempre como 644, ahí está la respuesta. Cambiar el umask en tu .bashrc/perfil es una decisión de seguridad: 002 es amigable para trabajo en equipo, 022 es el estándar, 077 es el bunker.

---

Casos reales: qué permiso poner y por qué

Situación	Permiso	Razonamiento
Clave privada SSH	600	OpenSSH literalmente se niega a usarla si es más permisiva
Directorio ~/.ssh	700	Nadie debe ni listar tu ssh_config
Script ejecutable tuyo	755	Tú escribes, todos ejecutan
Archivo de config web	640 + grupo www-data	La app lo lee, el mundo no
Dir compartido de equipo	2770	setgid para heredar grupo
Carpeta de uploads	755 o menos	Jamás ejecutable: los uploads no deberían correr código
Secretos en producción	400 o 600	Si la app ni siquiera puede reescribirlos, mejor

---

Por qué 777 nunca es la respuesta

Cuando pones chmod 777 estás diciendo "cualquier proceso, usuario o servicio de esta máquina puede leer, modificar y ejecutar esto". En un webroot eso significa que cualquier exploit mínimo de otro servicio puede reescribir tu código. En un directorio de datos, que cualquier usuario borra el trabajo de los demás.

El 99% de las veces que un 777 "arregla" algo, la solución real era una de estas:

• El archivo pertenece al usuario equivocado → chown al usuario correcto
• La app corre con otro grupo → añade ese grupo al archivo con chgrp + chmod g+r
• Varios usuarios necesitan acceso → crea un grupo, usa setgid en el directorio
• Casos realmente raros → ACLs con setfacl, que dan permisos por usuario concretos sin abrir a todos

Si no sabes qué combinación necesitas, juega con la calculadora chmod antes de tocar el servidor: marca quien debe poder hacer qué y copia el comando resultante. Veinte segundos de cálculo te ahorran la explicación incómoda de por qué había un rwxrwxrwx en producción.