¿umask cambia los permisos de los archivos que ya existen?

No. umask es una máscara que aplica solo en el momento en que un proceso CREA un archivo o directorio nuevo. Los archivos ya creados conservan sus permisos hasta que un comando los modifique explícitamente (por ejemplo, chmod). Cambiar umask afecta solo a lo que se cree de aquí en adelante.

¿Por qué los archivos nuevos no tienen permiso de ejecución por defecto?

Porque la máscara máxima de la que parte la fórmula es 666, no 777. El sistema asume que la mayoría de los archivos son datos, no programas, y que conceder ejecución debe ser una decisión explícita del usuario (con chmod +x). Si necesitas un script ejecutable, el flujo correcto es crearlo y luego añadir el bit de ejecución, no esperar que umask lo haga.

¿Es seguro usar umask 000?

No. umask 000 deja los archivos en 666 (rw-rw-rw-) y los directorios en 777 (rwxrwxrwx), lo que significa que cualquier usuario del sistema puede leer, escribir y, en el caso de directorios, modificar el contenido. Es lo contrario de un default seguro y prácticamente nunca tiene aplicación legítima fuera de entornos efímeros de pruebas.

¿Cómo se relaciona umask con chmod?

Son complementarios. umask define los permisos por defecto para archivos y directorios nuevos. chmod audita y modifica los permisos de los archivos ya existentes. Una rutina coherente usa umask para que los archivos nuevos partan en un estado razonable y chmod para ajustar puntualmente lo que se desvíe.

¿umask se aplica también cuando uso herramientas como cp o tar?

Depende. cp por defecto preserva los permisos del archivo origen si tiene acceso suficiente, así que umask no entra en juego en una copia normal. tar al extraer puede o no respetar umask según los flags y la versión. La regla práctica: umask interviene cuando se crea un fichero desde cero; cuando se restaura un archivo desde un backup conviene comprobar los permisos con ls -l.

Qué es umask en Linux y cómo elegir 022, 027 o 077

Cómo umask define los permisos por defecto en Linux: fórmula 666 & ~umask para archivos y 777 & ~umask para directorios, valores 022, 027, 077, 002, y por qué umask complementa a chmod en lugar de sustituirlo.

Qué hace umask

umask es una máscara que cada proceso hereda y que define los permisos con los que aterrizan los archivos y directorios nuevos que ese proceso crea. No es un comando que se ejecute sobre rutas existentes; es un valor del entorno del proceso (compartido entre el shell y los hijos que lanza) que el kernel consulta cuando se invoca open(O_CREAT) o mkdir. El kernel toma los permisos que el proceso pide, los enmascara con umask, y guarda el resultado.

Esa indirección importa porque permite definir defaults a nivel de sesión o de servicio sin tocar el código de cada herramienta. Si configuras umask 077 en tu shell, todo lo que se cree desde ese terminal nace en 600 / 700 sin que cada programa tenga que saberlo. El precio es que la máscara afecta a todo lo creado en esa sesión: hay que elegir un valor coherente con el rol del usuario.

umask no modifica archivos existentes

Es el malentendido más frecuente y conviene dejarlo claro de entrada: umask afecta exclusivamente al momento de creación. Si cambias umask en tu sesión, los archivos que ya existen en disco mantienen los permisos que tenían. Para auditar y arreglar permisos existentes — restringir un secret que se creó con defaults laxos, corregir un directorio web abierto de más — la herramienta correcta es chmod.

Esa frontera entre defaults y rectificación motiva la división de las dos calculadoras de ToolsOps: una para reglar defaults (umask) y otra para inspeccionar y rectificar permisos concretos (chmod). Ambas viven en el hub de permisos en Linux y se complementan: umask para el flujo de nuevo, chmod para el flujo de auditoría.

La fórmula: archivos 666 & ~umask, directorios 777 & ~umask

Para archivos regulares, el kernel parte de 666 (rw-rw-rw-) — el máximo aplicable a un archivo sin pedir ejecución explícita. Para directorios parte de 777 (rwxrwxrwx) — el máximo aplicable a un directorio, incluida la x que permite recorrerlo. Después aplica AND con el complemento de umask: los bits que umask activa se restan del máximo.

Ejemplos prácticos con la fórmula:

umask 022 → archivos 644 (rw-r--r--), directorios 755 (rwxr-xr-x).
umask 027 → archivos 640 (rw-r-----), directorios 750 (rwxr-x---).
umask 077 → archivos 600 (rw-------), directorios 700 (rwx------).
umask 002 → archivos 664 (rw-rw-r--), directorios 775 (rwxrwxr-x).
umask 000 → archivos 666, directorios 777 (defaults sin restricción; no es un valor recomendable).

Por qué los archivos no reciben execute por defecto

La elección de 666 como máximo para archivos no es arbitraria: el principio es que la ejecución sea una concesión explícita. Crear un fichero con el bit x activado por defecto significaría que cualquier dato (un CSV recién descargado, un YAML pegado en disco, un .sh que aún no se ha revisado) podría ejecutarse sin intervención. El sistema prefiere obligarte a teclear chmod +x cuando realmente quieres que algo sea ejecutable.

En directorios la situación es distinta: la x en un directorio no es ejecución de programa sino permiso para entrar en él (cd, listar contenido con stat, etc.), así que el máximo razonable es 777. La asimetría 666 / 777 entre archivos y directorios refleja esa diferencia semántica.

Diferencias entre 022, 027, 077, 002 y 000

Cada valor responde a un perfil de uso distinto. 022 es el default histórico en muchas distribuciones para entornos personales: el dueño mantiene control total y el resto del sistema puede leer. 027 endurece ese valor cerrando lectura a “others”, pero deja al grupo con lectura — útil cuando un grupo de trabajo comparte archivos sin querer exponerlos al sistema entero. 077 es el ajuste estricto: archivos solo accesibles al dueño, ningún acceso fuera. 002 se usa en entornos colaborativos donde el grupo escribe también — típico en servidores con un grupo de desarrolladores compartiendo un proyecto.

000 es la ausencia de máscara: deja todo permitido. Es lo opuesto a un default seguro y no debería usarse en estaciones de trabajo ni servidores. Aparece a veces en entornos efímeros de pruebas; fuera de ese contexto, no.

Qué elegir según el contexto

Estación personal de trabajo (single user): 022 es razonable para uso general. 077 si manejas información sensible y quieres reducir superficie por error humano (por ejemplo, al pegar un secreto en un fichero).
Servidor multi-usuario: 027 como punto de partida — preserva la posibilidad de lectura por grupo (útil para herramientas de monitorización o backup en un grupo específico) pero cierra a usuarios fuera del proyecto.
Carpetas compartidas con un grupo: 002 combinado con setgid en el directorio padre permite que todos los miembros del grupo escriban y que los archivos nuevos hereden el grupo del directorio. Es el patrón estándar para repositorios compartidos.
Secretos y claves SSH / TLS / GPG: 077. Los archivos deben ser únicamente del dueño. Después de crear la clave, el flujo correcto es verificar con ls -l que quedó en 600.

umask frente a chmod

Los dos comandos coexisten porque resuelven momentos distintos del ciclo de vida de un fichero. umask actúa cuando un proceso pide al kernel crear algo; es preventivo, define el estado inicial. chmod actúa cuando ya existe el archivo; es correctivo, ajusta el estado actual.

Una rutina coherente combina los dos: umask sensato a nivel de usuario o de servicio (027 o 077 según el rol), más una revisión periódica con chmod cuando algo se desvía. Para inspeccionar y ajustar permisos puntuales, la calculadora chmod permite traducir entre octal, simbólico y la salida de ls -l. Para el porqué detallado de los modos chmod, la guía chmod en Linux desgrana 755, 644, 777, setuid, setgid y sticky bit.

Cómo usar la calculadora umask

La calculadora umask de ToolsOps acepta valores octales de 3 dígitos y muestra el resultado para archivos y directorios en notación rwx, octal y simbólica. Es útil para confirmar antes de poner una línea en /etc/profile, en un systemd unit, o en un Dockerfile, qué permisos van a recibir realmente los archivos creados por ese contexto. Toda la lógica corre en tu navegador: el valor que introduces no sale de tu equipo.

Preguntas frecuentes

¿umask cambia los permisos de los archivos que ya existen?: No. umask es una máscara que aplica solo en el momento en que un proceso CREA un archivo o directorio nuevo. Los archivos ya creados conservan sus permisos hasta que un comando los modifique explícitamente (por ejemplo, chmod). Cambiar umask afecta solo a lo que se cree de aquí en adelante.
¿Por qué los archivos nuevos no tienen permiso de ejecución por defecto?: Porque la máscara máxima de la que parte la fórmula es 666, no 777. El sistema asume que la mayoría de los archivos son datos, no programas, y que conceder ejecución debe ser una decisión explícita del usuario (con chmod +x). Si necesitas un script ejecutable, el flujo correcto es crearlo y luego añadir el bit de ejecución, no esperar que umask lo haga.
¿Es seguro usar umask 000?: No. umask 000 deja los archivos en 666 (rw-rw-rw-) y los directorios en 777 (rwxrwxrwx), lo que significa que cualquier usuario del sistema puede leer, escribir y, en el caso de directorios, modificar el contenido. Es lo contrario de un default seguro y prácticamente nunca tiene aplicación legítima fuera de entornos efímeros de pruebas.
¿Cómo se relaciona umask con chmod?: Son complementarios. umask define los permisos por defecto para archivos y directorios nuevos. chmod audita y modifica los permisos de los archivos ya existentes. Una rutina coherente usa umask para que los archivos nuevos partan en un estado razonable y chmod para ajustar puntualmente lo que se desvíe.
¿umask se aplica también cuando uso herramientas como cp o tar?: Depende. cp por defecto preserva los permisos del archivo origen si tiene acceso suficiente, así que umask no entra en juego en una copia normal. tar al extraer puede o no respetar umask según los flags y la versión. La regla práctica: umask interviene cuando se crea un fichero desde cero; cuando se restaura un archivo desde un backup conviene comprobar los permisos con ls -l.