Permisos en Linux: usuarios, grupos, rwx y los errores que abren un sistema

2026-11-05 · 10 min de lectura

Aprende cómo funcionan los permisos en Linux (usuarios, grupos, lectura, escritura y ejecución), cómo leer y cambiar permisos con ls, chmod y chown, qué significan los permisos especiales y cuáles son los errores de permisos que más se aprovechan en los laboratorios.

Casi todo lo que ocurre en un sistema Linux pasa por una pregunta muy simple: ¿este usuario puede hacer esto con este archivo? La respuesta la dan los permisos. Entenderlos es la base para administrar un servidor, para auditarlo y para cualquier prueba de penetración: muchas de las escaladas de privilegios que verás en los laboratorios no son fallos de software, sino un permiso puesto donde no debía.

En Linux «todo es un archivo»: los documentos, los programas, los directorios, incluso los dispositivos y algunos canales de comunicación. Y todos tienen un propietario, un grupo y unos permisos. Si dominas esta lección, entenderás por qué un script de copia de seguridad escribible por todos, una clave privada legible o una carpeta mal protegida pueden terminar dando acceso de root.

En esta lección vas a ver cómo se organizan los usuarios y grupos, cómo se leen y se cambian los permisos, qué significan los permisos especiales, cómo se buscan configuraciones peligrosas y qué errores de permisos aparecen una y otra vez.

Practica en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Revisar o modificar archivos de sistemas ajenos sin permiso es un delito.

Usuarios y grupos#

Cada persona y cada servicio que usa un sistema Linux tiene un usuario con un número identificador (UID). El usuario root tiene el UID 0 y puede hacer cualquier cosa. Los servicios (el servidor web, la base de datos) suelen tener sus propios usuarios, como www-data o mysql, para que cada uno solo pueda tocar lo suyo.

Los usuarios se agrupan en grupos (con su identificador GID), lo que permite dar permisos a varias personas a la vez. Por ejemplo, todos los desarrolladores pueden pertenecer al grupo dev.

id
uid=1001(ana) gid=1001(ana) groups=1001(ana),27(sudo),998(docker)

Este resultado ya dice mucho: ana pertenece a sudo (puede usar sudo) y a docker (lo que, como verás en otra lección, equivale a root). Los usuarios están en /etc/passwd y los grupos en /etc/group; los hashes de las contraseñas, en /etc/shadow, que solo root puede leer.

Cómo se leen los permisos#

El comando ls -l muestra los permisos de cada archivo:

ls -l
-rwxr-x--- 1 ana dev  2048 informe.sh
drwxr-xr-x 2 ana ana  4096 proyectos

Cómo leer la cadena de permisos de ls -l: tipo, propietario, grupo y otros, cada uno con lectura, escritura y ejecución

La cadena de diez caracteres se lee así:

Posición	En el ejemplo	Significado
1	`-` o `d`	Tipo: `-` archivo, `d` directorio, `l` enlace simbólico
2–4	`rwx`	Permisos del propietario (ana)
5–7	`r-x`	Permisos del grupo (dev)
8–10	`---`	Permisos de otros: todos los demás usuarios

Y cada letra tiene un significado distinto según sea un archivo o un directorio:

Letra	En un archivo	En un directorio
`r` (lectura)	Leer su contenido	Listar los nombres de lo que contiene
`w` (escritura)	Modificar su contenido	Crear, borrar y renombrar archivos dentro
`x` (ejecución)	Ejecutarlo como programa	Entrar en él y acceder a sus archivos

Ese detalle de los directorios es importante: quien puede escribir en un directorio puede borrar o sustituir los archivos que contiene, aunque los archivos no sean suyos. Es la causa de muchas escaladas.

La notación numérica#

Los permisos también se expresan con números, sumando: lectura = 4, escritura = 2, ejecución = 1. Cada grupo de tres letras se convierte en una cifra:

Letras	Suma	Número
`rwx`	4 + 2 + 1	7
`rw-`	4 + 2	6
`r-x`	4 + 1	5
`r--`	4	4
`---`	0	0

Así, rwxr-x--- es 750, rw-r--r-- es 644 y rwxrwxrwx es 777 (cualquiera puede hacer cualquier cosa, casi siempre un error).

Cómo se cambian#

# Cambiar permisos con números
chmod 640 config.php          # rw-r----- : el propietario lee y escribe, el grupo lee

# Cambiar permisos con letras
chmod u+x script.sh           # añade ejecución al propietario (u = user)
chmod o-w archivo.txt         # quita escritura a otros (o = others)
chmod g=r informe.pdf         # el grupo solo puede leer

# Cambiar propietario y grupo
sudo chown ana:dev informe.sh

Solo el propietario del archivo (o root) puede cambiar sus permisos, y solo root puede cambiar su propietario.

La máscara por defecto: umask#

Cuando creas un archivo, sus permisos iniciales dependen de la umask, un valor que «resta» permisos. Con la umask habitual 022, los archivos nuevos quedan en 644 y los directorios en 755. Una umask demasiado permisiva (000) crea archivos que cualquiera puede modificar.

Los permisos especiales#

Además de rwx, existen tres permisos especiales que todo auditor debe reconocer:

Permisos especiales: SUID y SGID cambian con qué identidad se ejecuta un programa; el sticky bit protege carpetas compartidas

Permiso	Cómo se ve	Efecto	Valor
SUID	`rws` en el propietario	El programa se ejecuta como su propietario	4000
SGID	`rws` en el grupo	Se ejecuta con el grupo del archivo; en directorios, lo nuevo hereda el grupo	2000
Sticky bit	`t` al final (`rwxrwxrwt`)	En un directorio compartido, solo el dueño de cada archivo puede borrarlo	1000

El directorio /tmp tiene el sticky bit (drwxrwxrwt): todos pueden crear archivos, pero nadie puede borrar los de otros. Los binarios SUID tienen su propia lección en /aprende, porque son una de las vías de escalada más frecuentes.

Permisos más finos: las ACL#

Los permisos clásicos solo distinguen tres casos: propietario, un grupo y todos los demás. Cuando necesitas algo más preciso, como dar lectura a un usuario concreto sin meterlo en un grupo, Linux ofrece las listas de control de acceso (ACL).

# Ver las ACL de un archivo
getfacl informe.pdf

# Dar lectura a un usuario concreto
setfacl -m u:auditor:r informe.pdf

# Quitar todas las ACL extra
setfacl -b informe.pdf

Un archivo con ACL muestra un signo + al final de sus permisos en ls -l (por ejemplo -rw-r-----+). Si solo miras las letras, puedes pasar por alto que alguien más tiene acceso; por eso, al auditar, conviene revisar también las ACL con getfacl.

Cada servicio, su propio usuario#

Los permisos no protegen solo frente a personas: también limitan el daño cuando un servicio es comprometido. Si el servidor web se ejecuta como www-data y un atacante consigue ejecutar código a través de una vulnerabilidad web, obtendrá exactamente los permisos de www-data, ni uno más.

Por eso es tan importante que cada servicio tenga su propio usuario sin privilegios, que sus archivos solo sean modificables por quien debe modificarlos y que el usuario del servicio no pueda escribir en su propio código. Un servidor web que puede reescribir sus scripts PHP permite a un atacante dejar una puerta trasera permanente. En los laboratorios, la primera shell casi siempre llega como uno de estos usuarios de servicio, y la escalada consiste precisamente en buscar el permiso que alguien olvidó cerrar.

Errores de permisos que abren un sistema#

Error	Por qué es peligroso
Scripts ejecutados por root y escribibles por otros	Cualquiera añade comandos que root ejecutará
`/etc/passwd` o `/etc/shadow` escribibles	Se puede crear un usuario root o cambiar su contraseña
`/etc/shadow` legible por todos	Los hashes de contraseñas se pueden crackear
Claves SSH privadas legibles (`id_rsa` con 644)	Cualquiera entra como ese usuario
Archivos de configuración con contraseñas legibles	Credenciales de bases de datos o servicios expuestas
Directorios del PATH o de servicios escribibles	Se pueden sustituir programas por versiones maliciosas
`chmod 777` «para que funcione»	Elimina toda protección del archivo
Copias de seguridad legibles por todos	Contienen datos y credenciales completos

Cómo se buscan en un laboratorio#

En un laboratorio, tras entrar como un usuario normal, estas búsquedas descubren configuraciones peligrosas:

# Archivos que cualquiera puede modificar (excluyendo /proc y /sys)
find / -xdev -type f -perm -0002 2>/dev/null

# Directorios escribibles por todos sin sticky bit
find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null

# Archivos propiedad de root que tu usuario puede escribir
find / -xdev -user root -writable -type f 2>/dev/null

# ¿Puedo leer /etc/shadow o escribir en /etc/passwd?
ls -l /etc/passwd /etc/shadow

# Archivos de mi grupo y de otros grupos a los que pertenezco
find / -xdev -group dev 2>/dev/null

Un caso típico paso a paso#

Supón que en un laboratorio autorizado ls -l /etc/passwd muestra -rw-rw-rw-: cualquiera puede escribir en el archivo de usuarios. Como /etc/passwd admite una contraseña en lugar de la x, puedes generar un hash y añadir un usuario con UID 0:

openssl passwd -1 -salt wl Lab2026
# Devuelve un hash como $1$wl$...
echo 'soporte:HASH_GENERADO:0:0:soporte:/root:/bin/bash' >> /etc/passwd
su soporte

Tras escribir la contraseña Lab2026, eres root. Este fallo parece exagerado, pero aparece en laboratorios precisamente para mostrar el poder de un solo permiso mal puesto.

Cómo se corrige#

Mínimo privilegio: cada archivo, solo con los permisos que necesita. Configuraciones con secretos en 600 o 640; claves privadas SSH en 600; scripts del sistema en 755 y propiedad de root.
Nunca 777. Si algo «no funciona» por permisos, averigua qué usuario lo necesita y dale solo ese permiso a ese usuario o grupo.
Proteger las carpetas, no solo los archivos. Un archivo seguro dentro de una carpeta escribible no está seguro.
Revisar los archivos críticos: /etc/passwd en 644, /etc/shadow en 640 o 600 (grupo shadow), /etc/sudoers en 440.
Usar grupos para compartir acceso en lugar de abrir permisos a «otros».
Auditar periódicamente con las mismas búsquedas que haría un atacante, y vigilar cambios en archivos críticos con herramientas como AIDE o auditd.
Umask adecuada (022 o 027) para que los archivos nuevos no nazcan abiertos.

Errores comunes#

Dar 777 para resolver un problema. Arregla el síntoma y abre el sistema entero.
Olvidar los directorios. Quien escribe en un directorio puede sustituir sus archivos.
Pensar que «otros» no importa en un servidor de un solo usuario. Los servicios comprometidos (como www-data) son «otros».
Dejar copias de seguridad y archivos .bak en carpetas públicas con permisos amplios.
No revisar los permisos tras copiar o descomprimir archivos, que pueden conservar permisos inadecuados.

Preguntas frecuentes#

¿Qué significa chmod 755?#

Que el propietario puede leer, escribir y ejecutar (7), y el grupo y los demás pueden leer y ejecutar (5 y 5), pero no modificar. Es lo habitual para programas y directorios públicos.

¿Por qué root puede leer cualquier archivo aunque los permisos digan que no?#

Porque el sistema no comprueba los permisos normales para root: tiene, entre otras, la capacidad de saltárselos. Por eso las escaladas de privilegios buscan llegar a root.

¿Qué diferencia hay entre chmod y chown?#

chmod cambia qué se puede hacer con un archivo (los permisos). chown cambia de quién es (propietario y grupo).

¿Para qué sirve el sticky bit?#

Para que en una carpeta compartida, como /tmp, cada usuario solo pueda borrar sus propios archivos aunque todos puedan escribir en ella.

¿Cómo practico esto?#

En los laboratorios de whoami-labs enlazados al final de esta lección, pensados para aprender a enumerar permisos y descubrir archivos sensibles mal protegidos.

Resumen#

Cada archivo tiene propietario, grupo y permisos de lectura, escritura y ejecución para el propietario, el grupo y otros.
Los permisos se leen con ls -l, se cambian con chmod y el propietario con chown; en números, r=4, w=2, x=1.
En un directorio, la escritura permite borrar y sustituir lo que contiene.
Los permisos especiales SUID, SGID y sticky bit cambian identidades y protegen carpetas compartidas.
Los errores típicos (scripts escribibles, /etc/passwd modificable, claves legibles, 777) se buscan con find y se corrigen con mínimo privilegio.