Los permisos de archivos son el pilar de la seguridad en Linux. Todo administrador de sistemas conoce los permisos básicos — lectura, escritura y ejecución —, pero debajo de esa superficie hay un sistema más sofisticado que incluye bits especiales (SUID, SGID, Sticky Bit), listas de control de acceso (ACL) y la máscara de creación (umask). Dominar estos mecanismos es lo que separa a un usuario avanzado de un administrador profesional. Esta guía te lleva desde el repaso de los fundamentos hasta la auditoría completa de un servidor en producción.
📋 Repaso rápido del sistema rwx
Antes de adentrarnos en los permisos avanzados, conviene repasar cómo funciona el modelo de permisos clásico de Unix, diseñado por Ken Thompson y Dennis Ritchie en los laboratorios Bell a finales de los años 60. Este modelo ha sobrevivido más de cinco décadas porque combina simplicidad con eficacia: cada archivo y directorio tiene exactamente tres conjuntos de permisos — para el propietario (u), el grupo (g) y el resto del mundo (o) — y cada conjunto define tres operaciones posibles: lectura (r), escritura (w) y ejecución (x).
Internamente, Linux almacena los permisos como un número de 12 bits. Los 9 bits inferiores corresponden a los permisos rwx clásicos, mientras que los 3 bits superiores — que muchos administradores desconocen — controlan los permisos especiales SUID, SGID y Sticky Bit, que veremos en la siguiente sección.
ls -l muestra los permisos en formato simbólico (-rwxr-xr--), mientras que stat los muestra en formato octal (0754). Ambas representaciones son equivalentes.
| Permiso | Símbolo | Octal | En archivos | En directorios |
|---|---|---|---|---|
| Lectura | r | 4 | Leer contenido | Listar archivos (ls) |
| Escritura | w | 2 | Modificar contenido | Crear/eliminar archivos |
| Ejecución | x | 1 | Ejecutar como programa | Acceder (cd) |
🔒 SUID, SGID y Sticky Bit: los permisos especiales
Los tres bits superiores del sistema de permisos son los «permisos especiales» y controlan comportamientos que van más allá de la lectura, escritura y ejecución. Son herramientas poderosas — pero potencialmente peligrosas si se usan incorrectamente.
▶️ SUID (Set User ID) — bit 4 en posición especial
Cuando un ejecutable tiene activado el bit SUID, se ejecuta con los privilegios del propietario del archivo, no con los del usuario que lo invoca. El ejemplo más conocido es el comando passwd: cualquier usuario puede cambiar su propia contraseña, pero el archivo /etc/shadow solo es legible por root. El bit SUID permite que passwd se ejecute temporalmente como root para escribir en ese archivo.
▶️ SGID (Set Group ID) — bit 2 en posición especial
El SGID tiene un comportamiento dual según se aplique a archivos o directorios, y es precisamente en directorios donde brilla su utilidad práctica.
En archivos ejecutables, SGID funciona igual que SUID pero para el grupo: el programa se ejecuta con los privilegios del grupo propietario. En directorios, SGID tiene un efecto más interesante: todos los archivos y subdirectorios creados dentro heredarán automáticamente el grupo del directorio padre, en lugar del grupo primario del usuario que los crea. Esto es fundamental para proyectos colaborativos.
▶️ Sticky Bit — bit 1 en posición especial
El Sticky Bit, cuando se aplica a un directorio, impide que los usuarios eliminen o renombren archivos que no les pertenecen, aunque tengan permiso de escritura en el directorio. El ejemplo clásico es /tmp: todos los usuarios pueden crear archivos allí, pero ninguno puede borrar los archivos de otro usuario.
| Permiso especial | Octal | En archivos | En directorios | Se muestra como |
|---|---|---|---|---|
| SUID | 4000 | Se ejecuta como el propietario | Sin efecto en la mayoría de sistemas | s en posición x del propietario |
| SGID | 2000 | Se ejecuta con el grupo del archivo | Archivos nuevos heredan el grupo | s en posición x del grupo |
| Sticky Bit | 1000 | Sin efecto en Linux moderno | Solo el propietario puede borrar sus archivos | t en posición x de otros |
S o T mayúscula (en vez de s o t minúscula), significa que el bit especial está activado pero el permiso de ejecución subyacente está desactivado. Por ejemplo, -rwSr--r-- indica SUID activado pero sin permiso de ejecución para el propietario — una configuración que probablemente sea un error.
📂 ACLs: listas de control de acceso
El sistema rwx clásico tiene una limitación importante: solo permite definir permisos para un propietario, un grupo y todos los demás. ¿Qué ocurre cuando necesitas dar acceso de lectura a un usuario específico que no pertenece al grupo? Ahí es donde entran las ACLs (Access Control Lists).
Las ACLs permiten asignar permisos granulares a usuarios y grupos individuales sin modificar la propiedad del archivo ni crear grupos artificiales. Piensa en ellas como una extensión del sistema de permisos tradicional: los permisos rwx siguen existiendo, pero además puedes añadir reglas adicionales para usuarios o grupos específicos.
Instalar las herramientas ACL
La mayoría de distribuciones modernas incluyen soporte ACL por defecto. Los sistemas de archivos ext4, XFS y Btrfs lo soportan nativamente. Solo necesitas instalar las herramientas de usuario si no están ya presentes:
Asignar permisos con setfacl
r--, ningún usuario ni grupo de las ACLs tendrá permisos superiores a lectura, aunque la ACL diga rwx. La máscara se recalcula automáticamente al usar chmod, lo que puede producir resultados inesperados.
🎭 Umask: la máscara de creación de archivos
Cada vez que creas un archivo o directorio en Linux, los permisos iniciales no son los que defines tú, sino el resultado de restar la umask de los permisos base. Los permisos base son 666 para archivos (lectura y escritura) y 777 para directorios (lectura, escritura y ejecución). La umask determina qué permisos se eliminan automáticamente.
| Umask | Archivos (666-umask) | Directorios (777-umask) | Caso de uso |
|---|---|---|---|
0022 | 644 (rw-r--r--) | 755 (rwxr-xr-x) | Valor por defecto en la mayoría de distribuciones |
0077 | 600 (rw-------) | 700 (rwx------) | Máxima privacidad: solo el propietario tiene acceso |
0002 | 664 (rw-rw-r--) | 775 (rwxrwxr-x) | Entorno colaborativo: grupo tiene acceso completo |
0027 | 640 (rw-r-----) | 750 (rwxr-x---) | Servidor: grupo lee, otros sin acceso |
~/.bashrc (por usuario) o a /etc/profile (para todos los usuarios). En servidores web, una umask de 0027 es una buena práctica de seguridad.
📁 Permisos en archivos vs. directorios: diferencias clave
Uno de los errores más frecuentes al administrar permisos es asumir que rwx significa lo mismo en archivos y en directorios. La realidad es que el mismo permiso tiene comportamientos completamente diferentes según el tipo de recurso al que se aplique.
El permiso de ejecución es el que más confunde: en un archivo, x significa «puedes ejecutarlo como programa». En un directorio, x significa «puedes atravesarlo con cd y acceder a su contenido si conoces los nombres». Un directorio con r pero sin x permite listar nombres de archivos (con ls) pero no acceder a sus metadatos ni contenido. Un directorio con x pero sin r permite acceder a archivos específicos si conoces su nombre, pero no listar el contenido.
🔍 Auditoría de permisos
Mantener los permisos correctos en un servidor en producción es un trabajo continuo. Con el tiempo, errores humanos, instalaciones de software y operaciones automatizadas pueden dejar permisos incorrectos que representan vulnerabilidades. Una auditoría periódica es esencial.
find / -perm -4000 periódicamente y compara los resultados con una línea base conocida. Si aparece un nuevo archivo SUID que no corresponde a una actualización del sistema, investígalo inmediatamente — podría ser un indicador de compromiso.
🏗️ Ejemplo integrador: configurar un servidor compartido
Vamos a poner en práctica todo lo aprendido configurando un escenario realista: un servidor web donde tres equipos (desarrollo, diseño y contenido) comparten un directorio de proyecto. Cada equipo debe tener acceso completo a sus propios archivos, lectura sobre los de los demás, y los directorios compartidos deben estar protegidos contra borrados accidentales.
🐛 Errores frecuentes y soluciones
| Error | Causa | Solución |
|---|---|---|
chmod 777 para «solucionar» problemas | Abre el archivo a todo el mundo, creando un riesgo de seguridad | Identificar qué usuario/grupo necesita acceso y dar solo los permisos necesarios |
| Archivos nuevos no heredan el grupo esperado | Falta SGID en el directorio padre | chmod g+s directorio/ |
Las ACLs no funcionan tras chmod | chmod recalcula la máscara ACL, limitando permisos efectivos | Usar setfacl -m m::rwx archivo para restaurar la máscara |
Operation not permitted al borrar en directorio compartido | Sticky Bit activo — solo el propietario o root puede borrar | Comportamiento correcto. Si necesitas borrar, usa sudo o contacta al propietario |
| Script SUID no se ejecuta con privilegios elevados | Linux ignora SUID en scripts interpretados por seguridad | Compilar como binario o usar sudo con sudoers configurado |
✏️ Ejercicios prácticos
Crea un directorio /opt/lab-permisos con las siguientes condiciones: (a) pertenece al grupo labteam; (b) todos los archivos creados dentro heredan el grupo labteam; (c) ningún usuario puede borrar archivos de otro; (d) el usuario auditor tiene acceso de solo lectura a todo el contenido.
Ver solución
Escribe un script Bash que busque y liste: (a) todos los archivos SUID del sistema; (b) todos los archivos escribibles por todos que estén fuera de /tmp; (c) todos los archivos sin propietario. Guarda el resultado en /var/log/auditoria-permisos.log.
Ver solución
Configura el sistema para que los usuarios del grupo developers tengan una umask de 0002 (archivos compartidos con el grupo) y los del grupo finance tengan una umask de 0077 (archivos completamente privados). Pista: usa /etc/profile.d/.
Ver solución
❓ Preguntas frecuentes
¿SUID funciona en scripts de shell?
No. La mayoría de distribuciones Linux modernas ignoran el bit SUID en scripts interpretados (Bash, Python, Perl) por razones de seguridad. Si necesitas ejecutar un script con privilegios elevados, usa sudo con una entrada en /etc/sudoers.
¿Qué diferencia hay entre chmod 755 y chmod u=rwx,g=rx,o=rx?
Son equivalentes. La forma numérica (octal) es más compacta, mientras que la forma simbólica es más legible. La forma simbólica también permite añadir o quitar permisos individuales sin afectar a los demás (por ejemplo, chmod g+w).
¿Las ACLs sobreviven a una copia con cp?
Solo si usas cp --preserve=all o cp -a. Un cp simple no preserva las ACLs extendidas. Los backups con tar preservan ACLs solo si usas la opción --acls.
¿Puedo usar ACLs y permisos Unix simultáneamente?
Sí, se complementan. Los permisos Unix clásicos siempre están presentes y las ACLs se evalúan como capa adicional. El sistema comprueba primero si el usuario es el propietario (usa permisos de propietario), luego si hay una ACL específica para ese usuario, luego si pertenece al grupo o hay ACL de grupo, y finalmente aplica los permisos de «otros».
¿Cómo restauro los permisos predeterminados de un paquete instalado?
En distribuciones basadas en Debian, puedes usar apt install --reinstall paquete para restaurar los archivos con sus permisos originales. En Red Hat/CentOS, usa rpm --setperms paquete.
⚡ Permisos especiales en la práctica: casos reales
Comprender los bits especiales en teoría es una cosa; saber cuándo y dónde aparecen en un sistema real es otra completamente diferente. Vamos a examinar los escenarios más comunes donde un administrador de sistemas se encuentra con SUID, SGID y Sticky Bit en su trabajo diario.
Programas SUID que vienen con el sistema
Cada distribución Linux incluye un conjunto de programas con SUID activado. Estos programas necesitan privilegios elevados para funciones específicas y están cuidadosamente auditados. Los más comunes son: passwd (cambiar contraseñas), su y sudo (cambiar de usuario), ping (en algunas distribuciones, para acceder a sockets raw), mount y umount (montar sistemas de archivos cuando está configurado en fstab con la opción user), y chsh (cambiar la shell del usuario).
El principio de seguridad aquí es claro: cada programa SUID es un posible vector de ataque. Por eso, los administradores profesionales mantienen una línea base de archivos SUID legítimos y verifican periódicamente que no hayan aparecido nuevos. Si un atacante consigue colocar un binario SUID propiedad de root en el sistema, tendrá acceso root permanente sin necesidad de contraseña.
SGID en directorios de correo y colas de impresión
El SGID en directorios es la solución elegante al problema de los proyectos colaborativos. Sin SGID, cuando el usuario ana (cuyo grupo primario es ana) crea un archivo en un directorio compartido, el archivo pertenecerá al grupo ana, no al grupo del proyecto. Esto obliga a que cada miembro del equipo ejecute chgrp manualmente después de cada operación — algo que nadie hace en la práctica.
Con SGID activado en el directorio, todos los archivos y subdirectorios creados dentro heredarán automáticamente el grupo del directorio padre. Es la diferencia entre un directorio compartido que funciona y uno que genera tickets de soporte cada semana.
El Sticky Bit más allá de /tmp
Aunque /tmp es el ejemplo clásico, el Sticky Bit es igualmente útil en otros escenarios: directorios de colas de trabajo donde múltiples procesos depositan archivos, directorios de buzones de correo compartidos (/var/mail), y cualquier directorio donde varios usuarios necesiten escribir pero no deban poder eliminar el trabajo de otros.
Un patrón profesional muy común es combinar SGID y Sticky Bit (modo 3775): los archivos nuevos heredan el grupo correcto y están protegidos contra borrado accidental. Este es exactamente el patrón que usamos en el ejemplo integrador anterior.
🧰 Herramientas complementarias para gestión de permisos
Además de chmod, chown, setfacl y getfacl, Linux ofrece un ecosistema completo de herramientas para la gestión avanzada de permisos que todo administrador de sistemas debería conocer.
chattr e lsattr: atributos extendidos
Los atributos extendidos del sistema de archivos añaden una capa adicional de protección que va más allá de los permisos rwx. El atributo más conocido es el de inmutabilidad (+i): ni siquiera root puede modificar o eliminar un archivo inmutable sin quitarle primero el atributo. Es una salvaguarda extraordinaria para archivos de configuración críticos.
namei: diagnosticar problemas de permisos en rutas
Cuando un usuario no puede acceder a un archivo y los permisos del archivo parecen correctos, el problema suele estar en algún directorio del camino. El comando namei muestra los permisos de cada componente de una ruta, permitiendo identificar rápidamente dónde se rompe la cadena de acceso.
Capabilities: alternativa moderna a SUID
Las capabilities de Linux permiten asignar privilegios granulares a un programa sin necesidad de darle acceso root completo como hace SUID. En lugar de «este programa se ejecuta como root» (todo o nada), las capabilities dicen «este programa puede abrir puertos privilegiados» (solo lo que necesita). Es una mejora significativa en seguridad.
ping en distribuciones modernas usa cap_net_raw en lugar de SUID. Cada migración reduce la superficie de ataque del sistema.
🌐 Permisos en contexto: servidores web, contenedores y cloud
La teoría de permisos Unix tiene más de cinco décadas, pero sigue siendo la base de la seguridad en las infraestructuras más modernas. Un contenedor Docker, una instancia de AWS EC2 o un pod de Kubernetes — todos ejecutan Linux y todos dependen de los mismos permisos rwx que diseñaron Thompson y Ritchie. Sin embargo, cada contexto introduce matices que un administrador profesional debe conocer.
Permisos en servidores web (Apache/Nginx)
Los problemas de permisos son la causa número uno de errores «403 Forbidden» en servidores web. Apache se ejecuta típicamente como el usuario www-data (en Debian/Ubuntu) o apache (en Red Hat/CentOS). Para que pueda servir un archivo, necesita permiso de lectura en el archivo y permiso de ejecución en todos los directorios del camino hasta ese archivo.
La configuración correcta de permisos para un sitio web sigue un patrón estándar: los directorios deben tener modo 755 (el servidor web puede recorrerlos y listar su contenido), los archivos estáticos modo 644 (legibles por todos, escribibles solo por el propietario), y los scripts que necesitan ejecutarse (CGI, por ejemplo) modo 755. Los archivos de configuración sensibles como .htaccess o archivos con credenciales deben tener modo 640 o 600, legibles solo por el propietario y opcionalmente por el grupo.
chmod 777 en un servidor web: Es la «solución» que aparece en miles de tutoriales cuando alguien tiene un error 403. Funciona, sí — pero también permite que cualquier usuario del sistema (incluyendo otros sitios web en hosting compartido) lea, modifique y ejecute tus archivos. Si necesitas que el servidor web escriba en un directorio, usa 775 con el grupo correcto.
Permisos en contenedores Docker
Docker añade una capa de complejidad a los permisos porque el usuario dentro del contenedor puede tener un UID diferente al usuario del host. Por defecto, los procesos dentro de un contenedor se ejecutan como root (UID 0), lo que significa que los archivos creados en volúmenes montados pertenecerán a root en el host — algo que genera confusión constante.
La práctica profesional es ejecutar los contenedores con un usuario no privilegiado usando la directiva USER en el Dockerfile. Cuando el UID del usuario dentro del contenedor coincide con un UID del host, los permisos funcionan de forma transparente. Cuando no coinciden, es necesario usar --user al ejecutar el contenedor o configurar el mapeo de usuarios con userns-remap.
Permisos en entornos cloud (AWS, GCP, Azure)
En la nube, los permisos operan en dos niveles simultáneos: los permisos IAM del proveedor cloud (quién puede acceder a la instancia) y los permisos Linux tradicionales dentro de la instancia. Un error común es configurar correctamente IAM pero dejar los permisos del sistema de archivos demasiado abiertos, o viceversa. La seguridad efectiva requiere que ambas capas estén correctamente configuradas.
Las claves SSH para acceso a instancias EC2, por ejemplo, requieren permisos estrictos: el archivo de clave privada debe tener modo 600 (solo lectura para el propietario), el directorio ~/.ssh modo 700, y el archivo authorized_keys modo 644. Si los permisos son demasiado abiertos, SSH rechazará la conexión por motivos de seguridad — es una protección intencional del protocolo.
📊 Tabla resumen: permisos en acción
Esta tabla sintetiza los escenarios más comunes y la configuración de permisos recomendada para cada uno. Úsala como referencia rápida cuando necesites configurar permisos en situaciones reales.
| Escenario | Permisos | Modo octal | Justificación |
|---|---|---|---|
| Clave privada SSH | -rw------- |
600 |
Solo el propietario puede leerla |
| Script ejecutable personal | -rwxr-xr-x |
755 |
Todos pueden ejecutar, solo tú editar |
| Directorio de proyecto compartido | drwxrws--- |
2770 |
SGID + acceso solo para el grupo |
| Directorio /tmp | drwxrwxrwt |
1777 |
Sticky Bit protege contra borrado ajeno |
| Archivo de configuración sensible | -rw-r----- |
640 |
Propietario escribe, grupo lee, otros nada |
| Directorio web estático | drwxr-xr-x |
755 |
Servidor web puede recorrer y leer |
| Log de auditoría | -rw-r----- +a |
640 +a |
Append-only con atributo extendido |
| Directorio de uploads web | drwxrwsr-x |
2775 |
SGID + grupo del servidor web |
🎯 Conclusión: de usuario a administrador profesional
Los permisos en Linux son mucho más que chmod 755. Como hemos visto a lo largo de esta guía, el sistema de permisos de Unix es un modelo elegante y potente que, bien utilizado, proporciona seguridad robusta sin sacrificar la flexibilidad que necesitan los equipos de desarrollo modernos.
Los conceptos clave que debes dominar son: los permisos especiales (SUID, SGID y Sticky Bit) para resolver problemas específicos de acceso y colaboración; las ACL para cuando el modelo clásico usuario-grupo-otros se queda corto; el umask para garantizar permisos seguros por defecto; y las herramientas de auditoría (find, namei, getfacl) para diagnosticar y verificar la configuración de un sistema completo.
La diferencia entre un administrador junior y uno senior no está en conocer más comandos, sino en entender por qué se configura cada permiso de una manera específica y cómo interactúan los diferentes mecanismos entre sí. Con la práctica de los ejercicios propuestos y la aplicación del ejemplo integrador en entornos reales, estarás preparado para gestionar los permisos de cualquier infraestructura Linux con confianza y criterio profesional.
❓ Preguntas frecuentes sobre Gestión de permisos avanzada en Linux: SUID, SGID, ACL y umask
Las dudas más comunes respondidas de forma clara y directa.
💬 Foro de discusión
¿Tienes dudas sobre Gestión de permisos avanzada en Linux: SUID, SGID, ACL y umask? Comparte tu pregunta con la comunidad.
Todavía no hay mensajes. ¡Sé el primero en participar!
🎓 ¿Se puede aprender Linux con un curso bonificado por FUNDAE?
Sí. Todo lo que estás practicando en la terminal se puede llevar a un curso tutorizado de Bash y Shell Script bonificable al 100 % por FUNDAE si trabajas por cuenta ajena en España. Ciberaula es centro acreditado desde 1997.
Bash Scripting y Terminal Linux: Automatización de Sistemas (70 h) →
También te puede encajar: Administración de Sistemas Linux y Shell Script para Empresas → · Administración de Servidores Linux para Empresas: de Cero a Nivel Avanzado →
Ver todos los cursos de Linux bonificados del catálogo → · Ciberaula · Centro acreditado FUNDAE (Reg. 99000171) · 91 530 33 87 · admision@ciberaula.com