Linux umask Linux permisos de archivos chmod seguridad sysadmin permisos Linux

Guía Completa de Umask en Linux: Permisos de Archivos por Defecto Explicados

Publicado el 3 de junio de 2026 · Niwo

¿Qué es Umask?

Umask (abreviatura de user file-creation mode mask, máscara de modo de creación de archivos de usuario) es un mecanismo de seguridad fundamental en Linux y Unix que determina los permisos por defecto que se asignan a cada archivo y directorio recién creado. Cada vez que un proceso crea un archivo — ya sea touch, mkdir, un editor de texto al guardar un documento, un compilador al producir un objeto, o un servidor web al escribir sus logs — el kernel aplica la umask de ese proceso para calcular los permisos finales.

A simple vista, esto puede parecer un detalle menor. En la práctica, umask es una de las configuraciones más impactantes y, a la vez, más malentendidas de cualquier sistema Linux. Una umask mal configurada puede dejar archivos sensibles legibles por todo el mundo, mientras que una umask demasiado restrictiva puede romper flujos de trabajo legítimos en entornos compartidos.

El concepto central es simple: la umask define qué bits de permiso eliminar de los permisos base máximos. El kernel comienza con un conjunto de permisos base máximos — típicamente 666 (rw-rw-rw-) para archivos y 777 (rwxrwxrwx) para directorios — y resta lo que especifique la umask.

Punto clave: Cada proceso en ejecución en un sistema Linux hereda un valor de umask. Esto incluye tu shell, los demonios del sistema, los cron jobs, los contenedores Docker y las sesiones SSH. Entender y controlar la umask es esencial para asegurar cualquier entorno Linux.

Por qué Archivos y Directorios Tienen Permisos Base Distintos

Los permisos base difieren porque archivos y directorios cumplen propósitos fundamentalmente distintos:

• Archivos usan 666 por defecto (sin bit de ejecución) por seguridad — la mayoría de los archivos no deberían ser ejecutables a menos que se haga explícitamente. Añadir el bit de ejecución a un archivo de texto cualquiera podría crear un riesgo de seguridad.
• Directorios usan 777 por defecto (con bit de ejecución) porque el bit de ejecución en un directorio significa “permiso para entrar/atravesar” (cd hacia dentro). Sin el bit de ejecución, un directorio se vuelve inaccesible, lo que rompería los flujos de trabajo típicos.

La umask respeta esta distinción automáticamente: una umask de 022 en un archivo produce 644 (rw-r—r—), mientras que en un directorio produce 755 (rwxr-xr-x). El bit de ejecución se añade de vuelta para los directorios después de aplicar la máscara.

Cómo Funciona Umask

Umask opera mediante un modelo directo de sustracción:

Permisos por defecto = Permisos base − Valor umask

No se trata de una resta aritmética en el sentido decimal — es una operación a nivel de bits donde cada dígito (propietario, grupo, otros) se resta de forma independiente en octal. Piénsalo así: “comienza con los permisos base, luego desactiva los bits que la umask especifique.”

La Fórmula en Detalle

Este es el cálculo preciso:

1. Comienza con los permisos base: 666 para archivos, 777 para directorios.
2. Resta el valor umask dígito por dígito en octal (sin pedir prestado entre dígitos).
3. El resultado son los permisos por defecto que recibirá el nuevo archivo o directorio.

Veamos un ejemplo concreto. Con una umask de 022:

Para un archivo (base 666):

  rw- rw- rw-    (666)
- --- -w- -w-    (022)
= rw- r-- r--    (644)

Para un directorio (base 777):

  rwx rwx rwx    (777)
- --- -w- -w-    (022)
= rwx r-x r-x    (755)

Un punto de confusión común: 666 − 022 = 644 funciona perfectamente porque no se necesita pedir prestado. Pero 666 − 033 = ? NO es igual a 633. Veamos:

  rw- rw- rw-    (666)
- --- -wx -wx    (033)
= rw- r-- r--    (644)  ← NO es 633

¿Por qué? Porque en la resta octal, cada dígito es independiente. El 3 en octal es 011 en binario (bits de escritura y ejecución). Restar -wx de rw- para las posiciones de grupo y otros significa que intentamos eliminar el bit de escritura (que existe) y el bit de ejecución (que no existe en la base del archivo). El bit de ejecución nunca se estableció, así que eliminarlo no tiene efecto — solo se limpia el bit de escritura. El resultado es r-- (4), no -w- (3).

Vista de Complemento de Bits

Una forma técnicamente más precisa de entender la umask es mediante el complemento de bits:

permisos = base_permisos & ~umask

El kernel aplica AND con el NOT bit a bit de la umask. Esto significa: toma los permisos base y limpia todo bit que esté activo en la umask.

Por ejemplo, umask 022 (binario 000 010 010):

• ~022 = 111 101 101
• 666 & ~022 = 110110110 & 111101101 = 110100100 = 644

Esta vista a nivel de bits explica por qué establecer bits de umask que ya son cero en la base (como el bit de ejecución en un archivo) no tiene efecto — no se puede limpiar lo que ya está limpio.

La Regla del +x en Directorios

Uno de los comportamientos más pasados por alto: los directorios obtienen automáticamente el bit de ejecución incluso cuando la umask parecería eliminarlo. Esto se debe a que el kernel realiza un OR efectivo con el bit de ejecución en los directorios. Un directorio sin el bit de ejecución no puede ser accedido ni atravesado, por lo que el sistema se asegura de que siempre esté presente en los directorios recién creados.

La consecuencia práctica: con umask 077, los archivos nuevos obtienen 600 (rw-------) y los directorios nuevos obtienen 700 (rwx------). El bit de ejecución aparece en el directorio aunque la umask lo eliminaría — el kernel lo añade de vuelta después de aplicar la máscara.

Valores Comunes de Umask y su Significado

La siguiente tabla muestra los valores de umask más usados, los permisos resultantes para archivos y directorios, y sus casos de uso típicos. Usa nuestra Calculadora de Umask para experimentar con cualquier valor de forma interactiva — soporta cálculo directo e inverso con vista previa ls -l en vivo.

Cómo Elegir la Umask Adecuada

• Estación de trabajo personal (un solo usuario): 022 — equilibra conveniencia con seguridad razonable. Tus archivos son legibles por servicios del sistema y otros usuarios en la misma máquina, algo que la mayoría de usuarios de Linux de escritorio aceptan.
• Servidor web en producción: 027 — asegura que los archivos sean legibles por el grupo del proceso del servidor web pero no por usuarios no relacionados. Este es el valor recomendado para entornos de hosting compartido y servidores de aplicaciones.
• Servidor de desarrollo multiusuario: 002 — permite la colaboración en grupo. Los miembros del equipo en el mismo grupo de Unix pueden editar los archivos de los demás sin sudo. Combínalo con el bit setgid en directorios compartidos para un flujo de trabajo fluido.
• Entorno con requisitos de seguridad (PCI-DSS, HIPAA): 077 — bloquea todo al propietario. Cualquier proceso o usuario que necesite acceso debe recibirlo explícitamente. Este es el estándar para almacenamiento de claves SSH (~/.ssh), archivos de credenciales y claves privadas de certificados.

💡 Referencia interactiva: Usa nuestra Calculadora de Umask para ver cómo cada valor de umask afecta los permisos de archivos y directorios en tiempo real. Ingresa cualquier umask en modo octal o simbólico y obtén la salida ls -l resultante al instante.

Umask en Modo Octal vs Simbólico

Linux soporta dos sintaxis para especificar la umask: el clásico modo octal (numérico) y el más legible modo simbólico.

Modo Octal

El modo octal es la forma más común y concisa. La umask se expresa como un número octal de tres dígitos (o cuatro con cero inicial):

umask 022   # Archivos: 644, Directorios: 755
umask 027   # Archivos: 640, Directorios: 750
umask 002   # Archivos: 664, Directorios: 775

Los dígitos representan, de izquierda a derecha: propietario (usuario), grupo y otros. Cada dígito es la suma de los bits a eliminar:

• 4 = lectura (r) — eliminar permiso de lectura
• 2 = escritura (w) — eliminar permiso de escritura
• 1 = ejecución (x) — eliminar permiso de ejecución

Así que umask 027 significa: no eliminar nada del propietario (0), eliminar escritura del grupo (2), eliminar escritura y ejecución de otros (7 = 4+2+1).

Un cero inicial (ej. 0022) puede indicar una umask de cuatro dígitos. En la práctica, el primer dígito es casi siempre 0 y se refiere a los bits de modo especial (suid, sgid, sticky). Establecer estos bits en la umask evita que los archivos recién creados hereden permisos suid/sgid.

Modo Simbólico

El modo simbólico es más explícito y autodocumentado. El formato usa las mismas letras que chmod:

umask u=rwx,g=rx,o=rx   # Equivalente a 022
umask u=rwx,g=rx,o=     # Equivalente a 027
umask u=rwx,g=rwx,o=rx  # Equivalente a 002

En modo simbólico, especificas los permisos que quieres conservar en lugar de los bits a eliminar. Esto es el inverso del modo octal y puede ser más intuitivo:

• u=rwx,g=rx,o=rx significa: el propietario conserva todo, el grupo conserva lectura+ejecución, otros conservan lectura+ejecución.
• Esto se traduce a eliminar: nada del propietario, escritura del grupo, escritura de otros → 022.

Comprobar la Umask Actual

Ambas sintaxis funcionan para comprobar tu umask actual:

$ umask        # Salida octal
0022

$ umask -S     # Salida simbólica
u=rwx,g=rx,o=rx

El flag -S es particularmente útil al auditar scripts o archivos de configuración del sistema, ya que hace que la intención de los permisos sea inmediatamente clara.

¿Qué Modo Deberías Usar?

Octal es el estándar en los archivos de configuración del shell (/etc/profile, ~/.bashrc) porque es compacto y universalmente entendido. Simbólico es mejor en documentación y scripts donde la legibilidad importa, ya que elimina la aritmética mental de la resta octal.

Cómo Configurar Umask

La umask se puede configurar en múltiples niveles, desde los valores predeterminados del sistema hasta comandos individuales.

Configuración a Nivel de Sistema

Inicialización global del shell — afecta a todos los usuarios que inician sesión mediante shell:

# /etc/profile o /etc/bash.bashrc
umask 022

Configuración basada en PAM — se aplica a todos los usuarios independientemente del shell:

# /etc/login.defs
UMASK 022

Gestor de usuario de systemd — afecta a los servicios de usuario:

# ~/.config/systemd/user.conf
[Manager]
DefaultUmask=022

En sistemas Debian y Ubuntu, la umask por defecto se establece típicamente en /etc/login.defs y /etc/pam.d/common-session. Algunas distribuciones también ejecutan scripts en /etc/bashrc o /etc/profile.d/*.sh que establecen valores de umask.

Configuración por Usuario

La mayoría de los usuarios establecen su umask en los archivos de inicio de su shell:

# ~/.bashrc — se aplica a shells interactivos no login
umask 022

# ~/.profile — se aplica a shells login
umask 027

# ~/.zshrc — para usuarios de Zsh
umask 022

Importante: ~/.bashrc se lee para shells interactivos no login (emuladores de terminal), mientras que ~/.profile (o ~/.bash_profile) se lee para shells login (sesiones SSH, inicios de sesión en consola). Para un comportamiento consistente en todas las sesiones, establece la umask en ambos archivos o haz que uno ejecute al otro.

Umask por Comando y por Sesión

Puedes sobrescribir la umask para un solo comando usando un subshell:

# Ejecutar un comando con una umask diferente
(umask 077 && touch secreto.txt)

# El shell padre conserva su umask original
umask  # todavía muestra 022

Este patrón es extremadamente útil en scripts y cron jobs donde quieres permisos estrictos para archivos sensibles sin afectar el resto del entorno:

#!/bin/bash
# Script de backup: crear archivos comprimidos con permisos restringidos
(umask 077 && tar -czf backup-$(date +%F).tar.gz /datos/importantes)
# Archivo de log con permisos más amplios
(umask 022 && echo "Backup completado" >> /var/log/backup.log)

Umask en Servicios Systemd

Para servicios gestionados por systemd, establece la umask en el archivo de unidad:

[Service]
UMask=0027

Esta es la forma recomendada de controlar la máscara de creación de archivos para demonios como Nginx, Apache, PostgreSQL y servicios de aplicaciones personalizados. Puedes sobrescribirla usando systemctl edit <servicio> para crear un drop-in:

systemctl edit nginx

Luego añade:

[Service]
UMask=0027

Umask para Directorios Compartidos

Los directorios compartidos — donde múltiples usuarios necesitan colaborar en el mismo conjunto de archivos — presentan un desafío especial para la umask. La umask por defecto 022 crea archivos con permisos 644, lo que significa que solo el propietario del archivo puede escribir. Los demás miembros del grupo deben usar sudo o chmod después de cada creación de archivo, lo cual no es práctico.

La Estrategia 002 para Colaboración

Establecer la umask en 002 en los directorios compartidos de un equipo produce 664 (rw-rw-r—) para archivos y 775 (rwxrwxr-x) para directorios. Cualquier usuario en el mismo grupo puede leer y escribir archivos creados por cualquier otro miembro del grupo.

Para que esto funcione de forma fiable:

1. Crea un grupo común para el proyecto:

sudo groupadd webteam
sudo usermod -aG webteam alicia
sudo usermod -aG webteam bob

2. Establece el bit setgid en el directorio compartido. Esto fuerza a que todos los archivos y subdirectorios nuevos hereden el grupo del directorio padre:

sudo mkdir /var/www/proyecto
sudo chgrp webteam /var/www/proyecto
sudo chmod g+s /var/www/proyecto   # setgid

3. Configura una ACL por defecto para aplicar la política 002 automáticamente, independientemente de los ajustes de umask individuales:

setfacl -R -m g::rwx /var/www/proyecto
setfacl -R -m d:g::rwx /var/www/proyecto   # ACL por defecto para nuevos elementos

Las ACL Superan las Limitaciones de Umask

Las Listas de Control de Acceso (ACL) proporcionan una solución más robusta que la umask por sí sola para entornos compartidos. Una ACL bien configurada puede garantizar permisos mínimos independientemente de la umask que tenga cada usuario:

# Asegurar que el grupo siempre tenga rwx en /datos/compartido y todo su contenido nuevo
setfacl -R -m g:webteam:rwx /datos/compartido
setfacl -R -m d:g:webteam:rwx /datos/compartido

Con esta ACL establecida, incluso si un usuario tiene umask 077, los archivos nuevos en /datos/compartido seguirán otorgando acceso de lectura/escritura al grupo porque la ACL lo aplica. Este es un patrón potente para:

• Directorios de CI/CD donde los artefactos de compilación deben ser accesibles por las herramientas de despliegue.
• Repositorios compartidos (Git, SVN) donde múltiples desarrolladores suben código.
• Directorios de subida en aplicaciones web donde tanto el servidor web como los administradores necesitan acceso.

Advertencia importante: Cuando se establece una ACL por defecto en un directorio, el kernel combina la máscara de la ACL con la umask. Los permisos efectivos son la intersección de lo que la ACL concede y lo que la umask permite. Un usuario con umask 077 en un directorio protegido por ACL seguirá estando restringido — la ACL garantiza un máximo, no un mínimo. Educa a tu equipo sobre esta interacción.

Flujo de Trabajo Práctico para Hosting Compartido

Para un entorno de hosting compartido típico con múltiples desarrolladores:

# Configuración (una sola vez)
sudo groupadd developers
sudo usermod -aG developers $USER

# Por proyecto
sudo mkdir -p /srv/proyectos/miapp
sudo chgrp developers /srv/proyectos/miapp
sudo chmod g+ws /srv/proyectos/miapp   # setgid + escritura grupal
setfacl -R -m g:developers:rwx /srv/proyectos/miapp
setfacl -R -m d:g:developers:rwx /srv/proyectos/miapp

# Cada usuario añade a su ~/.bashrc:
umask 002

Ahora cada desarrollador en el grupo developers puede crear, editar y eliminar archivos dentro del directorio del proyecto sin errores de permisos — y el bit setgid asegura que los nuevos subdirectorios mantengan el grupo correcto.

Consideraciones de Seguridad

La umask es un control de defensa en profundidad. Aunque no reemplaza las políticas de control de acceso adecuadas, reduce la superficie de ataque al asegurar que los archivos recién creados no expongan accidentalmente datos sensibles.

Por Qué es Importante una Umask Restrictiva

Considera este escenario: un administrador de sistemas ejecuta un script de backup que vuelca una base de datos a un archivo. Si la umask es 022, el archivo de volcado se crea con permisos 644 — legible por todos los usuarios del sistema. Cualquier usuario local con una cuenta de shell puede leer las credenciales de la base de datos y los datos de los clientes. Una umask de 077 habría restringido ese archivo solo al propietario, conteniendo la brecha a cuentas que ya tienen acceso root o sudo.

Ejemplos reales de vulnerabilidades relacionadas con umask:

• Claves privadas SSH (id_rsa, id_ed25519): SSH requiere estrictamente que tengan permisos 600. Si tu umask produce archivos más permisivos, ssh se negará a usar la clave con un error de “permisos incorrectos”. Esta es una frustración común al generar claves en sistemas con configuraciones de umask no estándar.
• Archivos .env de aplicaciones web: Los archivos de configuración del framework que contienen claves de API, contraseñas de bases de datos y secretos de cifrado nunca deberían ser legibles por todo el mundo. Una umask restrictiva es una red de seguridad adicional más allá de la propiedad adecuada de archivos.
• Directorios de logs: Los logs de aplicaciones pueden contener PII, tokens de sesión o salida de depuración. Una umask de 022 los hace legibles por todos los usuarios locales.

Umask Recomendada por Entorno

Permisos de Claves SSH — Un Caso Especial

OpenSSH es famoso por ser estricto con los permisos de los archivos de clave:

~/.ssh/id_rsa debe ser 600 (o menos permisivo)
~/.ssh/ debe ser 700 (o menos permisivo)
~/.ssh/config debe ser 600 (o menos permisivo)
~/.ssh/authorized_keys debe ser 600 (o menos permisivo)

Si tu umask es demasiado permisiva al generar claves SSH, verás:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         ADVERTENCIA: ¡ARCHIVO DE CLAVE PRIVADA           @
@                   NO PROTEGIDO!                          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Los permisos 0644 para '/home/usuario/.ssh/id_rsa' son demasiado abiertos.

La solución es directa: establece la umask en 077 antes de generar claves, o corrige los permisos después:

umask 077
ssh-keygen -t ed25519 -C "[email protected]"
# O corregir claves existentes:
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

Entornos Containerizados

En contenedores Docker, el comportamiento de la umask depende de la imagen base y el entrypoint. Muchas imágenes oficiales establecen la umask en 022 por defecto. Para contenedores que manejan datos sensibles:

# Dockerfile
FROM alpine:latest
RUN umask 027
# o establécela en el entrypoint
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

#!/bin/sh
# entrypoint.sh
umask 027
exec "$@"

Para despliegues en Kubernetes, puedes establecer la umask mediante un security context o init container:

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  capabilities:
    add: ["SETUID", "SETGID"]

Sin embargo, Kubernetes no expone directamente un campo umask — debes manejarlo en el script entrypoint de tu contenedor.

Solución de Problemas

Las malas configuraciones de umask son una fuente común de problemas relacionados con permisos en sistemas Linux. Estos son los problemas más frecuentes y cómo diagnosticarlos.

Error 1: Asumir la Misma Base para Todos los Archivos

El error más común con la umask es olvidar que los archivos y los directorios tienen permisos base diferentes. Una umask que produce directorios 755 producirá archivos 644, no archivos 755. Los nuevos administradores suelen esperar que los scripts ejecutables se creen con el bit de ejecución activo, pero la umask no añade bits — solo los elimina.

Solución: Haz los scripts ejecutables explícitamente con chmod +x script.sh. No confíes en la umask para producir ejecutables.

Error 2: Olvidar que los Directorios Reciben el Bit de Ejecución

Al calcular permisos manualmente, es fácil olvidar que el kernel añade el bit de ejecución de vuelta para los directorios después de aplicar la máscara. Esto es por diseño — un directorio sin +x no se puede acceder — pero puede confundir los cálculos manuales.

Ejemplo: Con umask 111, el cálculo para un archivo es 666 - 111 = 555 (r-xr-xr-x). Pero para un directorio, 777 - 111 = 666 (rw-rw-rw-), y luego el kernel añade ejecución de vuelta: rwxrwxrwx (777). Esto es idéntico a la umask 000 para directorios — un resultado que a menudo sorprende.

Error 3: Confusión con la Resta Octal

Como se explicó antes, la resta octal es independiente dígito por dígito. 666 - 033 no es igual a 633. El 3 en octal representa -wx. Como los archivos no tienen el bit de ejecución en su base (666), eliminar wx solo limpia el bit de escritura, dejando 644.

Esta confusión está tan extendida que muchos administradores abogan por usar el modo simbólico (umask -S) exclusivamente para mayor legibilidad.

Cómo Comprobar la Umask Actual

# Umask del shell actual
umask
umask -S

# Umask de otro usuario (si tienes acceso)
sudo -u www-data bash -c 'umask'

# Umask de un proceso en ejecución
cat /proc/<PID>/status | grep Umask

# Para un proceso específico por nombre
pgrep -x nginx | while read pid; do
  echo "PID $pid: $(cat /proc/$pid/status | grep Umask)";
done

Depuración de Problemas de Permisos

Cuando un usuario se queja de “permiso denegado” en un archivo recién creado, revisa esta lista:

1. Comprueba los permisos del archivo: ls -la archivo — ¿son los que esperas?
2. Comprueba la umask del usuario que creó el archivo: sudo -u $USUARIO bash -c 'umask'
3. Comprueba los permisos y ACLs del directorio padre: getfacl /ruta/al/dir
4. Comprueba las opciones de montaje del sistema de archivos: mount | grep /ruta — algunos sistemas de archivos (como NFS con all_squash) ignoran la umask.
5. Comprueba si SELinux o AppArmor están involucrados: ls -Z archivo — los sistemas MAC pueden sobrescribir los permisos estándar.

Efectos de Diferentes Sistemas de Archivos

El comportamiento de la umask puede variar entre sistemas de archivos:

• ext4, XFS, Btrfs: Comportamiento POSIX estándar de umask.
• FAT32 / exFAT / NTFS (vía FUSE): Estos sistemas de archivos no soportan permisos Unix de forma nativa. Las opciones de montaje (uid=, gid=, fmask=, dmask=) controlan los permisos efectivos, y la umask del kernel tiene un efecto limitado.
• NFS: La umask del servidor y las opciones de exportación no_all_squash/all_squash interactúan con la umask del cliente. NFSv4 con Kerberos añade otra capa de complejidad.
• tmpfs / ramfs: Soporte POSIX completo de umask.

# Ejemplo: montar una unidad USB FAT32 con permisos explícitos
sudo mount -t vfat -o uid=1000,gid=1000,fmask=113,dmask=002 /dev/sdb1 /mnt/usb
# fmask=113 → 664 para archivos, dmask=002 → 775 para directorios

Preguntas Frecuentes

¿Cuál es la umask por defecto en Linux?

La umask por defecto varía según la distribución:

El archivo /etc/login.defs controla el valor predeterminado del sistema. La mayoría de las distribuciones modernas usan 022 por defecto, que ha sido el estándar desde los años 90. Algunas distribuciones reforzadas en seguridad (como las variantes con SELinux habilitado o builds gubernamentales) pueden usar 027 o 077 por defecto.

¿Cómo compruebo la umask actual?

Ejecuta el comando umask sin argumentos para ver el valor actual en octal:

$ umask
0022

Para la salida simbólica (más legible):

$ umask -S
u=rwx,g=rx,o=rx

Para comprobar la umask de un proceso en ejecución (ej. un servidor web):

$ cat /proc/$(pgrep -x nginx | head -1)/status | grep Umask
Umask:  0022

¿Qué umask debo usar para un directorio compartido?

Para un directorio compartido donde múltiples usuarios en el mismo grupo necesitan colaborar, usa umask 002. Esto produce 664 (rw-rw-r—) para archivos y 775 (rwxrwxr-x) para directorios, permitiendo que todos los miembros del grupo lean y escriban los archivos de los demás.

Para máxima colaboración sin acceso mundial, combina umask 002 con:

• Un grupo de Unix dedicado para el proyecto
• El bit setgid (chmod g+s) en el directorio compartido
• Reglas ACL por defecto (setfacl -m d:g:nombre_grupo:rwx) para un comportamiento consistente independientemente de las configuraciones individuales de umask

Consulta la sección Umask para Directorios Compartidos para una guía completa.

Umask 022 vs 002 — ¿cuál debería usar?

Elige 022 para estaciones de trabajo personales, servidores monousuario y entornos donde los archivos no deberían ser modificados accidentalmente por otros miembros del grupo.

Elige 002 para servidores de desarrollo, hosting compartido, pipelines CI/CD y cualquier entorno donde múltiples usuarios en el mismo grupo necesiten escribir en archivos compartidos sin escalar privilegios.

Si la seguridad es una prioridad, considera 027 en lugar de 022 — deniega el acceso de lectura a otros mientras mantiene la colaboración del grupo intacta.

¿Cómo configuro la umask de forma permanente?

Para hacer que los cambios de umask persistan entre reinicios y sesiones de inicio de sesión:

1. Para todos los usuarios: Añade umask 027 a /etc/profile o /etc/bash.bashrc. Esto afecta a todos los usuarios de shells compatibles con Bourne.

2. Para todos los usuarios login vía PAM: Edita /etc/login.defs y establece UMASK 027. Esto afecta a los shells login independientemente del tipo de shell (sh, bash, zsh, etc.).

3. Para un usuario específico: Añade umask 027 a ~/.bashrc, ~/.profile o ~/.zshrc. Recuerda que ~/.bashrc es para shells interactivos no login y ~/.profile es para shells login. Añádelo a ambos para una cobertura completa.

4. Para servicios systemd: Usa UMask=0027 en la sección [Service] del archivo de unidad o un drop-in mediante systemctl edit <servicio>.

Después de hacer cambios, verifica con una nueva sesión de inicio de sesión:

ssh usuario@host 'umask'   # Debería mostrar 0027

Conclusión

Umask es uno de esos fundamentos de Linux que parecen simples en la superficie pero revelan una profundidad creciente cuanto más trabajas con él. Entender cómo funciona el modelo de sustracción — y sus limitaciones — es esencial para todo administrador de sistemas, ingeniero DevOps y usuario de Linux que se preocupe por la seguridad.

Aquí tienes un resumen rápido de lo que recordar:

• Umask resta bits de permiso de la base (666 para archivos, 777 para directorios).
• Los archivos nunca ganan el bit de ejecución a través de la umask — usa chmod +x explícitamente.
• Los directorios recuperan automáticamente el bit de ejecución después de aplicar la umask — esto es normal.
• 022 es el valor por defecto universal pero puede no ser el adecuado para tu caso de uso.
• 002 permite la colaboración en grupo sin escalada de privilegios.
• 027 es el mínimo recomendado para servidores en producción.
• 077 es obligatorio para claves SSH, credenciales y datos sensibles.
• Las ACL complementan la umask en entornos compartidos y proporcionan un control más granular.
• Siempre verifica con umask y ls -la antes de asumir que los permisos son correctos.

El hábito más importante que puedes desarrollar: sé intencional con tu umask. No aceptes el valor por defecto sin entender si sirve a tus necesidades de seguridad. Unos segundos dedicados a configurar la umask correcta pueden ahorrarte horas de depuración de permisos — y prevenir incidentes de exposición de datos.

¿Listo para dominar los cálculos de umask? Usa la Calculadora de Umask de Tecniwao para probar cualquier valor de umask al instante. Ingresa una umask en modo octal o simbólico, ve los permisos resultantes de archivos y directorios en formato ls -l, observa el desglose a nivel de bits, e incluso calcula de forma inversa qué umask produce un conjunto de permisos objetivo. Sin registro, resultados en tiempo real.