Umask en Linux: guía práctica para definir los permisos por defecto

umask (user file-creation mode mask) es la máscara de permisos que se aplica en el momento de crear un archivo o directorio. No cambia lo que ya existe; influye en cómo “nacen” los nuevos objetos del sistema de archivos.

En mi experiencia, cuando varias personas trabajan en el mismo servidor o carpeta compartida, una umask bien pensada te ahorra roces y tickets. Me he repetido mil veces que, en Linux, “todo es archivo o directorio”; por eso, los permisos por defecto importan tanto como los que ajustas después. Si tu equipo colabora y la umask es demasiado restrictiva, rompes el flujo (nadie puede editar lo recién creado). Si es demasiado laxa, abres puertas que no querías abrir.

Conceptualmente, las aplicaciones suelen pedir permisos “base”:

Archivos: 666 (rw-rw-rw-) → por defecto no se da x a los archivos.
Directorios: 777 (rwxrwxrwx).

Luego entra umask y quita bits. Por eso es crucial recordar que umask nunca añade permisos; sólo los resta. Para añadir o cambiar permisos de algo que ya existe, usarás chmod, ACLs u otros mecanismos.

Micro-nota práctica que me funciona: decide la umask por contexto (escritorio, carpeta de proyecto, servicio systemd) y documenta el porqué. La “umask por defecto” rara vez sirve para todo.

Cómo se calculan los permisos: de 666/777 a `R = D & (~M)`

La fórmula mental rápida:

D = permisos base solicitados (666 para archivos, 777 para directorios).
M = umask (la máscara).
R = permisos resultantes = D & (~M) (operación bit a bit).

Ejemplos típicos:

umask	Archivos nuevos	Directorios nuevos	Comentario
000	666 (-rw-rw-rw-)	777 (drwxrwxrwx)	Todo abierto (raro y riesgoso).
002	664 (-rw-rw-r–)	775 (drwxrwxr-x)	Colaboración en grupo sin fricciones.
007	660 (-rw-rw—-)	770 (drwxrwx—)	Grupo cerrado; nadie fuera del grupo entra.
022	644 (-rw-r–r–)	755 (drwxr-xr-x)	Clásico en estaciones individuales.
027	640 (-rw-r—–)	750 (drwxr-x—)	Buen equilibrio seguridad/colaboración.
077	600 (-rw——-)	700 (drwx——)	Máxima privacidad (útil para servicios).

A mí me ha salvado más de una vez tener 002 en carpetas de proyecto compartido: todos pueden leer/escribir, y otros usuarios del sistema no estorban.

Octal vs simbólico: usando `umask` y `umask -S`

Octal: umask 022, umask 027, etc. Es la forma más común.
Ver en simbólico (legible tipo chmod): umask -S (por ejemplo, para 022 suele mostrarse u=rwx,g=rx,o=rx).
Imprimible (para scripts): umask -p devuelve una línea reutilizable como umask 022.

Ver y cambiar tu umask

Cambio temporal (sólo esta sesión/shell)

# Ver el valor actual en octal y en simbólico
umask
umask -S

# Cambiar sólo para esta shell (y subshells)
umask 002

Este ajuste se pierde cuando cierras la sesión o el proceso que lo estableció. En scripts, la umask del proceso padre puede afectar el resultado si tú no fijas una explícita al inicio.

Consejo que me ha evitado sustos: al principio de los scripts que crean archivos, deja claro tu umask. Ej.: umask 077 para credenciales.

Configuración permanente por usuario (`~/.bashrc`, perfiles)

Para Bash interactivo, añade a ~/.bashrc:

# ~/.bashrc
umask 022

Para shells de login (primera sesión textual o SSH), también puedes ponerlo en ~/.profile o ~/.bash_profile según distro/shell. En Zsh, ~/.zshrc. Tras editar, abre una nueva sesión o recarga: . ~/.bashrc.

Nota: si tu distro usa “user private groups”, a veces es razonable 002 para trabajo colaborativo dentro del mismo grupo del usuario.

Configuración a nivel de sistema (`/etc/profile`, PAM y servicios)

Global interactivo: /etc/profile (y en algunas distros /etc/bash.bashrc). Úsalo con criterio: afectará a todos los usuarios interactivos.
PAM (inicio de sesión): el módulo pam_umask permite definir/forzar umasks en el login (archivos en /etc/pam.d/). Útil en entornos multiusuario o con políticas centralizadas.
Servicios systemd: cada servicio puede tener su propia umask:

# /etc/systemd/system/mi-servicio.service
[Service]
UMask=007

Luego: sudo systemctl daemon-reload && sudo systemctl restart mi-servicio.

En mi día a día, separar umask de usuarios (p. ej., 022/002) de la umask de servicios (a menudo 077) me ha dado tranquilidad: los binarios escriben con lo mínimo necesario.

Valores recomendados según escenario

Escritorio individual (comodidad vs privacidad)

Si trabajas en tu propia cuenta y rara vez compartes archivos con otros usuarios del mismo host, 022 suele ser cómodo: los nuevos archivos salen como 644 y las carpetas 755. Nadie ajeno puede escribir en tus cosas, pero sí leer si tiene acceso al path. Si te preocupa la lectura por terceros locales (logs con datos sensibles, por ejemplo), podrías optar por 027 (archivos 640, carpetas 750) y añadir al grupo sólo a quien deba leer.

Inserción personal: “Los permisos que nacen con el archivo importan tanto como los que ajustas después.” En mi caso, cuando sé que voy a generar reportes con datos internos, bajo a 027 y me olvido de tener que “chmodear” luego.

Colaboración en grupo (`002`) sin romper el flujo

Para directorios compartidos entre usuarios del mismo grupo, 002 es oro: archivos 664 y carpetas 775. Así, quien comparta el grupo puede editar lo recién creado sin molestarte para que cambies permisos. Complementa con:

# Carpeta de proyecto compartida
sudo chgrp -R mi-grupo /ruta/proyecto
sudo chmod -R 2775 /ruta/proyecto   # bit setgid en directorios para heredar grupo
umask 002                           # en sesiones que trabajen ahí

El bit setgid (2xxx) en directorios hace que todo lo nuevo herede el grupo del directorio, manteniendo la colaboración fluida.

En entornos compartidos, me he encontrado con fricción constante cuando la umask era 022: el autor podía editar, su grupo no. Con 002 esa fricción desaparece.

Máxima seguridad (`027`/`077`) y servicios (ej. web)

En servidores y procesos que manipulan credenciales o datos sensibles, 077 es una postura fuerte: archivos 600 y carpetas 700; nadie fuera del usuario del proceso puede leer o escribir. Para servicios que necesitan que el grupo lea (pero no el resto), 027 equilibra bien.

Para servicios systemd, define UMask=077 en la unidad y revísalo en logs si el servicio espera permisos más abiertos. A veces aplicaciones web crean directorios de subida o caché y fracasan si no pueden ser leídos por el proceso HTTP: ajusta grupo/propiedad y, si es imprescindible, rebaja a 027 en ese servicio concreto.

“Si varios usuarios colaboran, una umask demasiado restrictiva o demasiado laxa rompe el flujo.” En servicios, prefiero pecar de restrictivo y abrir sólo lo necesario.

Errores comunes con umask y cómo evitarlos

Subshells, scripts y herencia de entorno

Cada proceso tiene su umask. Si un script ejecuta otro (subshell), hereda el valor a menos que lo cambies. Por eso:

Declara tu umask al inicio de scripts que creen archivos: umask 077.
En cron/systemd, la umask por defecto puede ser distinta a tu shell interactiva. Declárala explícitamente.
En sesiones SSH, el stack de PAM puede aplicar pam_umask y sorprenderte. Comprueba con umask nada más entrar.

Diferencias con `chmod` y con ACLs

umask: sólo afecta a lo que aún no existe. No puede añadir permisos; sólo los quita del valor base.
chmod: modifica permisos de objetos existentes (puede añadir o quitar).
ACLs (Access Control Lists): permiten reglas más finas. Los ACLs por defecto en un directorio pueden afinar o incluso redefinir lo que esperas de la umask para objetos creados dentro. Si tu carpeta tiene ACLs por defecto, revisa getfacl; quizá la umask no explique por sí sola el resultado.

Checklist rápido cuando “no cuadran” los permisos recién creados:

¿Qué umask tiene el proceso que crea? (strace -e umask o imprime umask al inicio del script).
¿Hay ACL por defecto en el directorio padre? (getfacl .).
¿El servicio tiene UMask= propia en systemd?
¿El directorio usa setgid para heredar grupo? (ls -ld y busca s en el grupo).

Pequeña lección que aprendí a golpes: cuando diagnostiques “por qué este archivo nació con 640 y no 664”, mira el directorio padre y el proceso que lo creó, no sólo tu shell.

FAQs rápidas sobre umask

¿Puedo hacer que los archivos nazcan con permiso de ejecución?
No por umask: la herramienta que crea el archivo debe solicitar x. Umask sólo quita, no añade.

¿Umask 002 es inseguro?
Depende. En un host multiusuario y sin aislamiento, dar escritura al grupo puede ser indeseable. En un equipo donde todos pertenecen al mismo grupo de proyecto, 002 es práctico.

¿Dónde pongo la umask para SSH?
Puedes fijarla en ~/.bashrc/~/.profile. Si tu organización usa PAM, se puede imponer vía pam_umask (pregunta a quien administre el stack PAM).

¿Por qué umask -S me muestra u=rwx,g=rx,o=rx con umask 022?
Es la representación simbólica equivalente; lo importante es que 022 → archivos 644 / directorios 755.

¿Cambia algo con contenedores/Docker?
Sí: cada contenedor/proceso tiene su propia umask. Declárala en la entrypoint o en el propio servicio que corre dentro, y controla permisos de volúmenes compartidos.

Sobre Umask

umask es una palanca pequeña con impacto grande. Si trabajas en entornos compartidos, decidir la umask por contexto evita sorpresas: 002 para colaborar sin fricción, 022 para estaciones individuales, 027/077 cuando la privacidad manda, y UMask= específico en servicios. Al final, los permisos con los que “nacen” tus archivos pueden ahorrarte (o generarte) mucho trabajo.

Opinión Personal

Si algo he aprendido en Linux es que umask no es un detalle técnico, es política operativa. Define cómo “nacen” tus archivos y, con ello, tu modelo de confianza. En entornos compartidos, defenderé siempre 002 para no frenar a tu equipo; nada mata más la colaboración que un archivo recién creado que el resto no puede editar. En servidores y procesos con datos sensibles, mi postura es clara: 077 o, como mínimo, 027. Prefiero pecar de restrictivo en servicios y abrir sólo lo imprescindible, que al revés.

Otra manía que mantengo: declarar la umask explícitamente en scripts y unidades systemd. Confiar en valores heredados es invitar a los “¿por qué este fichero salió con 640?”. Y si un proyecto es realmente colaborativo, combino umask 002 + setgid en el directorio para heredar grupo y evitar el baile de permisos.

En resumen, no existe una umask universal. Documenta el contexto, fija el valor acorde al riesgo y no la dejes a la deriva. Te ahorras fricciones, incidencias y, a veces, sustos.

¿Tú qué opinas? ¿Qué umask usas y por qué? Déjame tus comentarios abajo: leo y respondo para seguir la conversación.