Usuarios, grupos y permisos en Linux

Cada comando se ejecuta con una identidad. Linux utiliza esa identidad para decidir qué archivos puede abrir el comando y qué configuraciones puede cambiar. Una cuenta de usuario puede representar a una persona o a un servicio que se ejecuta en segundo plano.

El número detrás del nombre

El núcleo identifica una cuenta por su identificador de usuario (UID). Los nombres como alice facilitan el reconocimiento del número, pero los permisos siguen al número. La cuenta root tiene el UID 0 y su directorio personal es /root. Una cuenta con otro nombre y UID 0 tiene los mismos privilegios de superusuario.

Un usuario normal es la cuenta cotidiana de una persona. En la mayoría de las distribuciones, los UID de usuarios normales empiezan en 1000; UID_MIN en /etc/login.defs establece ese límite. Un usuario normal puede modificar sus propios archivos y cualquier otro archivo que permitan los permisos. Para cambiar la configuración protegida del sistema se necesitan privilegios elevados.

Una cuenta del sistema da a un servicio su propia identidad limitada. La mayoría tiene UID inferiores a 1000 y un intérprete como /usr/sbin/nologin. La cuenta especial nobody suele tener el UID 65534, por lo que el rango por sí solo no identifica todas las cuentas de servicio. Debian y Ubuntu utilizan www-data para los servicios web; un servicio SSH puede utilizar sshd.

Consulta tu identidad actual

Ejecuta whoami para ver tu nombre de usuario o id para ver los números y grupos. Por ejemplo:

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1005(developers)

Interpreta la salida en tres partes. El UID de Alice es 1001. Su grupo principal es alice, con GID 1001. Su lista de grupos también incluye sudo y developers. Es una usuaria normal, no root: el grupo sudo puede autorizar comandos con privilegios elevados, pero su intérprete actual sigue ejecutándose como Alice.

Muchos intérpretes muestran # para root y $ para un usuario normal. El indicador de comandos se puede personalizar, así que consulta id cuando la identidad sea importante. La primera cuenta creada durante la instalación suele ser una cuenta normal con acceso a sudo, también en Ubuntu; ser la primera cuenta creada no la convierte en root.

Comprueba las sesiones de inicio de sesión

Estos comandos responden a una pregunta distinta de whoami: informan sobre sesiones, no solo sobre la identidad de tu intérprete. Debian 13 es uno de los sistemas que utiliza wtmpdb para su historial.

Las identidades separadas favorecen el mínimo privilegio, la trazabilidad de las acciones y el aislamiento. Un servicio web puede leer los archivos que sirve sin obtener los documentos privados de todos los usuarios. Los registros pueden mostrar qué cuenta actuó. Si el servicio se ve comprometido, el ataque comienza con los permisos de esa cuenta de servicio. Root puede eludir las restricciones ordinarias de lectura y escritura de archivos, por lo que una segunda cuenta con UID 0 supone un problema grave de seguridad.

Compartir un archivo con un equipo es más fácil cuando el equipo tiene un grupo. Asigna el archivo a ese grupo, dale los permisos necesarios y gestiona sus miembros a medida que se incorporan o se marchan personas.

Un grupo principal y pertenencias adicionales

Un grupo tiene un nombre y un identificador de grupo (GID) numérico. Cada usuario tiene un grupo principal, almacenado como GID en /etc/passwd. Un archivo nuevo suele adoptar el grupo principal del proceso que lo crea. Más adelante, un directorio con SGID proporcionará otra regla para asignar el grupo de un archivo nuevo.

Los usuarios también pueden tener varios grupos suplementarios. Esas pertenencias añaden identidades de grupo a sus procesos; el usuario no necesita cambiar de grupo principal cada vez que abre el archivo de otro equipo. Tanto el grupo principal como los suplementarios cuentan cuando Linux comprueba si el usuario pertenece al grupo de un archivo.

La mayoría de las distribuciones crean un grupo privado de usuario junto con cada usuario normal. Alice puede tener el nombre de usuario alice, UID 1001, grupo principal alice y GID 1001. Siguen siendo identidades de usuario y grupo separadas aunque sus nombres y números coincidan. Un archivo asignado al grupo privado de Alice no se comparte con todo el equipo.

Inspecciona la pertenencia a un grupo

Usa groups para ver los nombres de tus propios grupos. groups bob e id bob consultan los grupos a los que pertenece Bob; id -Gn muestra los nombres de los grupos del proceso actual sin números. Una consulta de grupo podría mostrar:

getent group developers
developers:x:1005:alice,bob

El grupo se llama developers, su GID es 1005 y Alice y Bob aparecen como miembros suplementarios. Una cuenta cuyo GID principal sea 1005 también pertenece al grupo, aunque su nombre no figure en esa última lista. Para comprobar todos los grupos de una persona, usa id con su nombre en lugar de depender solo de esa lista.

Aplica los permisos de un grupo

Supongamos que plan.txt pertenece a bob:developers y tiene el modo rw-r-----. Alice no es Bob, pero pertenece a developers. Por tanto, utiliza la terna de permisos central, r--: puede leer el plan, pero no puede modificar su contenido. Chen no es el usuario propietario ni pertenece al grupo, así que utiliza la última terna, ---.

Cambiar el nombre de grupo asignado a un archivo no crea permisos por sí mismo. Si su terna de grupo es ---, los miembros siguen sin recibir acceso mediante esa clase. El grupo propietario identifica al equipo; los bits de permisos especifican qué puede hacer el equipo.

Reconoce los grupos con privilegios amplios

Algunas pertenencias conceden mucho más que acceso a una carpeta de proyecto. Debian y Ubuntu suelen autorizar al grupo sudo para ejecutar comandos de administración; Fedora y Red Hat Enterprise Linux suelen usar wheel. En Debian y Ubuntu, adm permite acceder a muchos registros del sistema. El grupo docker controla el servicio Docker y proporciona, en la práctica, control de nivel root.

Antes de añadir a alguien a un grupo, identifica a qué puede acceder. Un grupo de proyecto puede ser una forma limitada de compartir trabajo, mientras que un grupo de administración puede conceder control sobre toda la máquina.

Linux mantiene los datos públicos de las cuentas separados de los datos de contraseñas. Leer el orden de los campos te ayuda a explicar la identidad de una cuenta, su configuración de inicio de sesión y su política de contraseñas sin cambiar los archivos a mano.

Lee un registro de cuenta

/etc/passwd tiene siete campos separados por dos puntos:

name:password:UID:GID:comment:home:shell
alice:x:1001:1001:Alice Moreau:/home/alice:/bin/bash

El UID y el GID principal de Alice son ambos 1001. El comentario, también llamado campo GECOS, indica su nombre completo. Su directorio personal es /home/alice y su intérprete de inicio de sesión es Bash. La x apunta a los datos de contraseña de /etc/shadow; no significa que su contraseña esté vacía.

Los usuarios normales pueden leer /etc/passwd, que normalmente tiene el modo 644. Los programas necesitan sus datos públicos para convertir los UID almacenados en nombres. Mantener los resúmenes criptográficos de las contraseñas en un archivo protegido separado impide que todos los usuarios locales puedan leerlos.

Lee los datos de contraseñas

/etc/shadow tiene nueve campos: nombre, resumen criptográfico de la contraseña, día del último cambio, vigencia mínima, vigencia máxima, días de aviso, días de inactividad, día de caducidad de la cuenta y un campo reservado. Root puede leerlo; algunos sistemas también conceden acceso al grupo shadow.

El resumen criptográfico de una contraseña es un resultado unidireccional, no un cifrado reversible. Al iniciar sesión, el sistema aplica el método y la sal almacenados a la contraseña introducida y después compara el resultado con el resumen almacenado. Una sal criptográfica aleatoria hace que los resúmenes sean distintos incluso cuando dos usuarios eligen la misma contraseña. Los registros de SHA-512 crypt utilizan $6$salt$hash, opcionalmente con un campo rounds=N; yescrypt utiliza $y$parameters$salt$hash.

Un ! inicial bloquea la contraseña y conserva el resumen. Un campo que contiene solo !, !! o * no tiene ninguna contraseña utilizable. Otros métodos de inicio de sesión, como las claves SSH, pueden seguir funcionando con una contraseña bloqueada.

Calcula las fechas

Considera este registro con el resumen abreviado:

alice:$y$j9T$...:20514:0:90:7:::

Las fechas cuentan los días desde el 1 de enero de 1970, UTC. El día 20514 es el 2 de marzo de 2026. Una vigencia mínima de 0 permite cambiar la contraseña inmediatamente; una máxima de 90 implica que caduca el 31 de mayo de 2026. El aviso de siete días comienza el 24 de mayo. Los campos vacíos de inactividad y caducidad de la cuenta no establecen ninguno de esos límites. Un valor de último cambio de 0 obliga a cambiar la contraseña en el siguiente inicio de sesión; un máximo de 99999 supone, en la práctica, una vigencia muy larga. La caducidad de la contraseña y la de la cuenta son campos distintos.

Lee los registros de grupos de forma segura

/etc/group utiliza name:password:GID:members. En developers:x:1005:alice,bob, el último campo lista los miembros suplementarios. Los miembros principales se encuentran mediante el GID de sus registros en passwd. El archivo protegido /etc/gshadow almacena los datos de contraseñas y administradores de grupos.

Usa getent passwd alice o getent group developers para hacer consultas. getent consulta las fuentes de cuentas configuradas además de los archivos locales. cut -d: -f1,3 /etc/passwd muestra los nombres y UID locales. Modifica los registros con comandos de gestión de cuentas como usermod y passwd; si la edición directa es inevitable, vipw y vigr bloquean los archivos durante la edición.

Las tareas de administración necesitan más acceso que el trabajo diario. Mantén tu intérprete habitual bajo tu propia cuenta y eleva los privilegios para la acción que los necesite. Los archivos creados por un comando con privilegios elevados pueden pertenecer a root incluso cuando están dentro de tu directorio personal.

Elige sudo o su

Un intérprete de inicio de sesión carga el entorno de inicio de sesión del usuario de destino, incluidos el directorio personal y los archivos de inicio. Usa exit para salir de un intérprete iniciado con su. sudo -i abre un intérprete de inicio de sesión de root; sudo -s abre un intérprete de root. Son útiles para una serie de tareas de administración relacionadas, pero todos los comandos de ese intérprete tienen privilegios elevados hasta que sales.

Sudo comprueba su política antes de ejecutar el comando y registra el intento. Los registros pueden ir al registro de systemd, a /var/log/auth.log en sistemas de la familia Debian o a /var/log/secure en sistemas de la familia Red Hat. sudo -l muestra los comandos que tu cuenta puede ejecutar. El permiso para usar sudo depende de la política, no de conocer la contraseña de otra persona.

Comprende la autenticación

De forma predeterminada, sudo pide la contraseña del usuario que lo ejecuta, no la de root. La política puede cambiar ese comportamiento. La marca de tiempo de autenticación de sudo en su proyecto de origen dura cinco minutos de forma predeterminada; las distribuciones pueden configurar otro valor, como 15 minutos. La marca de tiempo normalmente se aplica dentro de ese terminal. Ejecuta sudo -k para invalidarla cuando termines.

Ubuntu normalmente comienza sin una contraseña de root utilizable y añade al usuario de la instalación a sudo. Fedora y los sistemas de la familia Red Hat suelen usar wheel. Un intento denegado puede indicar que el usuario no está en el archivo sudoers; el intento queda registrado.

Ejecuta la operación de escritura con sudo

Este comando falla cuando tu cuenta normal no puede escribir en /etc/hosts:

sudo echo "192.0.2.10 test.local" >> /etc/hosts

Tu intérprete actual abre el archivo para >> antes de que sudo se ejecute. Solo echo recibe permisos de root, y echo no es el programa que abre el destino. Asigna la tarea de escritura a un proceso con privilegios elevados:

echo "192.0.2.10 test.local" | sudo tee -a /etc/hosts

Aquí tee abre el archivo protegido como root. Su opción -a añade al final; omitirla sustituiría el contenido del archivo. Para una edición interactiva, sudoedit /etc/hosts, también escrito sudo -e /etc/hosts, ejecuta tu editor con tu identidad y se encarga de actualizar el archivo protegido.

Detecta el trabajo propiedad de root

Después de sudo mkdir ~/project, inspecciona el resultado con ls -ld ~/project. El directorio está en tu directorio personal, pero fue creado por root. Por tanto, sus permisos de propietario se aplican a root, mientras que tu cuenta puede tener solo acceso de lectura y ejecución. Restablece el propietario deseado con sudo chown alice: ~/project cuando el proyecto pertenezca a Alice. Los dos puntos finales también seleccionan el grupo de inicio de sesión de Alice. Después, la edición y la creación normales de archivos pueden ejecutarse bajo la cuenta de Alice.

Una regla de sudo decide quién puede ejecutar una acción, en qué sistema anfitrión y con qué identidad. Conceder a un equipo una acción de administración puede cubrir sus necesidades sin darle control ilimitado sobre la máquina.

Lee las partes de una regla

El patrón básico es who where = (as_whom) what. Por ejemplo:

alice ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

La primera regla permite a Alice ejecutar cualquier comando en cualquier sistema anfitrión como cualquier usuario y grupo. La segunda concede los mismos permisos al grupo sudo; % indica un nombre de grupo. Una regla habitual de la familia Red Hat es %wheel ALL=(ALL) ALL.

Para conceder a Alice todos los permisos de administrador mediante una regla existente de la distribución, ejecuta sudo usermod -aG sudo alice en Debian o Ubuntu, o utiliza wheel en Fedora y sistemas relacionados. Alice debe iniciar una sesión nueva para que la pertenencia llegue a su sesión. La opción -a es importante: sin ella, -G sustituye sus otros grupos suplementarios.

Edita y comprueba la política

El archivo principal es /etc/sudoers; puede haber reglas adicionales en /etc/sudoers.d/. Usa sudo visudo o un archivo específico:

sudo visudo -f /etc/sudoers.d/webteam

visudo bloquea el archivo de política durante la edición y comprueba su sintaxis antes de guardarlo. Una política incorrecta puede impedir que los administradores usen sudo. Llama al archivo webteam, no webteam.conf: el tratamiento de directorios incluidos de sudo omite los nombres que contienen un punto o terminan en ~.

Los archivos del directorio incluido se leen por orden de nombre. Cuando varias reglas coinciden, la última que coincide determina el resultado; la regla que parece más específica no prevalece necesariamente. La inclusión suele estar cerca del final de la política principal, por lo que un archivo adicional puede afectar a una regla escrita antes.

Concede una acción exacta

Un equipo que mantiene un servicio web podría recibir:

%webteam ALL=(root) /usr/bin/systemctl restart nginx

Un miembro puede ejecutar sudo systemctl restart nginx. La regla especifica la ruta completa del comando y sus argumentos. No autoriza systemctl stop nginx ni bash. Comprueba los permisos efectivos con sudo -l; un administrador puede inspeccionar la política de Bob con sudo -l -U bob.

El programa permitido también importa. Un intérprete de root puede hacer cualquier cosa. Los editores y paginadores pueden iniciar intérpretes, y cp o tee sin restricciones pueden sobrescribir configuraciones protegidas. Por tanto, una lista de comandos aparentemente corta puede conceder control completo.

Decide si se necesita una contraseña

NOPASSWD: elimina la solicitud de autenticación para un comando que coincida:

backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh

Esto puede servir para una tarea automatizada. El guion debe estar bajo el control de root: si backup puede reescribirlo, la cuenta puede sustituir su contenido por cualquier comando de root. Mantén la acción permitida limitada y protege también el guion.

Las líneas Defaults cambian la configuración de la política. Defaults timestamp_timeout=10 establece una marca de tiempo de autenticación de diez minutos; Defaults logfile=/var/log/sudo.log selecciona un archivo de registro adicional. Estos ajustes controlan el comportamiento de sudo, mientras que las reglas de comandos controlan las acciones que autoriza.

Crear una cuenta configura una identidad, un entorno de inicio de sesión y, a menudo, un directorio personal. Elegir las opciones explícitamente hace que el resultado sea predecible en distintas distribuciones.

Crea una cuenta normal

Supongamos que el grupo developers ya existe. Crea la cuenta de Priya y establece su contraseña con dos comandos:

sudo useradd -m -s /bin/bash -c "Priya Shah" -G developers priya
sudo passwd priya

-m crea /home/priya y copia los archivos iniciales de /etc/skel. -s /bin/bash selecciona Bash como intérprete de inicio de sesión y -c proporciona el comentario. -G developers añade la pertenencia a un grupo suplementario; varios nombres de grupo forman una lista separada por comas y sin espacios. La cuenta normalmente también recibe un grupo principal privado.

El primer comando añade registros de cuenta a /etc/passwd y /etc/shadow, y registros de grupo según sea necesario a /etc/group y /etc/gshadow. Su campo de contraseña inicial está bloqueado, a menudo con ! o !!. La cuenta existe antes de tener una contraseña utilizable. passwd priya establece esa contraseña; su solicitud evita que la contraseña aparezca en la línea de comandos.

Comprende los valores predeterminados de las distribuciones

useradd es el comando de bajo nivel para crear cuentas que se utiliza en las distribuciones de Linux. Debian y Ubuntu también proporcionan un guion interactivo adduser que pide datos y crea un directorio personal. En los sistemas de la familia Red Hat, adduser es otro nombre para useradd, por lo que no ofrece el mismo proceso interactivo.

Sin opciones explícitas, useradd depende de los valores predeterminados locales. Los valores de la familia Red Hat suelen crear un directorio personal; los de Debian y Ubuntu no lo hacen a menos que se indique -m. El intérprete predeterminado también puede variar. Consulta useradd -D para ver valores como la ubicación base de los directorios personales y el intérprete. /etc/default/useradd y /etc/login.defs proporcionan ajustes como los rangos de UID, los grupos privados y la vigencia de las contraseñas.

Indica otro directorio personal o identidad

Las opciones útiles describen partes distintas de la cuenta:

Una ruta de directorio personal en el registro no crea el directorio por sí misma. Combina -d con -m cuando haya que crear el nuevo directorio personal. En Debian, omitir -m puede dejar una cuenta por lo demás válida sin un directorio personal que utilizar al iniciar sesión.

Para una identidad de servicio, sudo useradd -r -s /usr/sbin/nologin backupsvc solicita un UID del sistema y un intérprete no interactivo. Las cuentas del sistema no tienen directorio personal de forma predeterminada. El intérprete de acceso denegado impide iniciar una sesión interactiva ordinaria bajo esa identidad.

Verifica la configuración

Ejecuta getent passwd priya, id priya y ls -la /home/priya. Comprueba la ruta del directorio personal, el intérprete, el grupo principal, los grupos adicionales y los archivos ocultos copiados. /etc/skel es una plantilla: añadir .bash_aliases allí afecta a la creación posterior de directorios personales, no a los que ya existen. Usa nombres de cuenta sencillos en minúsculas con dígitos, guiones o guiones bajos después de la primera letra; muchas herramientas rechazan o gestionan mal los espacios y los nombres inusuales.

Una cuenta puede necesitar una contraseña nueva, otro directorio personal, un bloqueo temporal del acceso o una eliminación permanente. Estas operaciones cambian partes distintas de la cuenta, así que identifica el resultado deseado antes de elegir un comando.

Cambia una contraseña o establece su vigencia

Ejecuta passwd para cambiar tu propia contraseña, normalmente después de introducir la actual. Un administrador usa sudo passwd priya para establecer la contraseña de Priya sin conocer la anterior. Las comprobaciones de calidad pueden rechazar contraseñas cortas o simples.

sudo passwd -S priya informa del estado de la contraseña. sudo passwd -l priya bloquea la contraseña colocando ! delante de su resumen, y sudo passwd -u priya la desbloquea. sudo passwd -e priya hace caducar la contraseña para que el usuario deba elegir otra en el siguiente inicio de sesión. Hacer caducar una contraseña es útil cuando se entrega una temporal.

Usa sudo chage -l priya para consultar las fechas de vigencia. Por ejemplo:

sudo chage -M 90 -m 1 -W 7 priya

La vigencia máxima es de 90 días, la mínima entre cambios es de un día y los avisos comienzan siete días antes de la caducidad. Estos valores se guardan en /etc/shadow. sudo chage -E 2026-12-31 priya establece la fecha de caducidad de toda la cuenta, por separado de la vigencia de su contraseña.

Bloquea el acceso sin eliminar registros

El bloqueo de una contraseña impide la autenticación mediante contraseña. No elimina las claves SSH ni detiene todos los demás métodos de autenticación. Para deshabilitar los futuros inicios de sesión de la cuenta de un usuario que se marcha, bloquea la contraseña y establece una fecha de caducidad de la cuenta ya pasada, como con sudo usermod -e 1 priya. El valor 1 es un recuento de días de enero de 1970, por lo que esa fecha ya ha pasado. Esto no termina los procesos que ya están en ejecución; requieren atención por separado.

Modifica una cuenta existente

usermod puede cambiar el comentario con -c, el intérprete con -s y la ruta del directorio personal con -d. Combina -d y -m para mover el contenido del directorio personal, como en sudo usermod -d /data/priya -m priya. -l newname cambia el nombre de inicio de sesión, pero el directorio personal y el grupo privado conservan sus nombres actuales a menos que también se cambien. -L y -U bloquean y desbloquean la contraseña.

Para añadir la pertenencia a un grupo suplementario, ejecuta sudo usermod -aG developers priya. La opción -a indica que se añada. Sin ella, usermod -G developers priya sustituye toda la lista de grupos suplementarios de Priya; una pertenencia previa a sudo puede desaparecer. Su grupo principal es un ajuste independiente controlado por -g.

Elimina la cuenta y gestiona sus archivos

sudo userdel priya elimina los registros de la cuenta, pero conserva el directorio personal. sudo userdel -r priya también elimina el directorio personal y el buzón de correo. El comando normal se niega a eliminar la cuenta mientras el usuario tenga procesos en ejecución.

Los archivos situados en otras partes conservan su UID numérico de propietario. Después de eliminar la cuenta, un listado puede mostrar 1003 como propietario porque no hay ningún nombre asociado a ese número. Reutilizar ese UID para una cuenta nueva da a esa cuenta la propiedad de los archivos antiguos. Usa sudo find / -nouser para localizar archivos sin un usuario correspondiente y después archívalos o reasígnalos. Cuando alguien se marcha, bloquea primero los futuros inicios de sesión, atiende la actividad en ejecución y conserva los archivos necesarios; después elimina la cuenta cuando esas tareas estén completas.

Una carpeta compartida necesita un grupo, miembros y permisos de directorio que permitan trabajar a esos miembros. La base de datos de cuentas y los grupos de un intérprete que ya está en ejecución pueden discrepar temporalmente después de un cambio de pertenencia.

Crea y mantén el grupo

sudo groupadd developers asigna el siguiente GID disponible. Añade -g 1500 para elegir un GID concreto o -r para crear un grupo del sistema. Compruébalo con getent group developers; un último campo vacío significa que todavía no hay miembros suplementarios en la lista.

Añade un miembro con cualquiera de los dos comandos:

sudo usermod -aG developers priya
sudo gpasswd -a priya developers

sudo gpasswd -d priya developers elimina esa pertenencia suplementaria. sudo gpasswd -M alice,bob developers establece toda la lista de miembros y sustituye la anterior. Elige entre añadir, eliminar o sustituir según el cambio deseado.

Actualiza los grupos de una sesión

Después de añadir a Priya, id priya consulta la base de datos de cuentas y muestra la nueva pertenencia inmediatamente. id sin argumentos en su intérprete existente informa de los grupos que ese intérprete está utilizando realmente. Esos grupos se establecieron al comenzar la sesión.

Un nuevo inicio de sesión carga la nueva lista. newgrp developers ofrece otra vía: inicia un nuevo intérprete con developers como grupo principal. Usa exit para salir de ese intérprete. Cuando diagnostiques una operación denegada, inspecciona la identidad de la sesión que intenta realizarla, no solo la entrada de la base de datos.

Renombra o elimina un grupo

sudo groupmod -n devteam developers cambia el nombre, pero conserva el GID. Los archivos existentes siguen haciendo referencia al mismo grupo numérico. En cambio, sudo groupmod -g 1600 developers cambia el número del grupo. Los archivos que aún tienen el GID anterior 1005 requieren atención; localízalos con sudo find / -gid 1005 y después usa chgrp para asignarles el grupo deseado.

sudo groupdel developers se niega a eliminarlo si un usuario existente todavía lo tiene como grupo principal. Establece otro grupo principal con usermod -g antes de eliminarlo. Eliminar el nombre de un grupo no borra los archivos que tienen su antiguo GID.

Configura una carpeta de equipo

Para el equipo web de Priya y Kenji:

sudo groupadd webteam
sudo usermod -aG webteam priya
sudo usermod -aG webteam kenji
sudo mkdir /srv/web
sudo chgrp webteam /srv/web
sudo chmod 2770 /srv/web

Después de iniciar sesiones nuevas, ambos usuarios pueden crear archivos en /srv/web. El modo 2770 da rwx al propietario y al grupo, --- a otros, y establece SGID en el directorio. Un archivo nuevo adopta el grupo webteam, incluso cuando el grupo principal de quien lo crea es su grupo privado. Los subdirectorios nuevos también heredan SGID.

El directorio permite aprovechar la pertenencia al equipo e impide la entrada a otros, pero cada archivo sigue teniendo su propio modo. Con la solicitud habitual de archivo 666, una umask de 002 de quien lo crea da escritura al grupo, mientras que 022 deja al grupo con solo lectura. Si los miembros del equipo necesitan editar los archivos de los demás, comprueba estos valores predeterminados de creación además de la carpeta.

Un listado en formato largo reúne en una línea la información necesaria para decidir el acceso. Lee el propietario y el grupo junto con los nueve bits de permisos; los bits por sí solos no indican qué permisos recibe una persona concreta.

Interpreta un listado en formato largo

-rw-r----- 1 priya developers 2048 Oct 22 09:15 report.txt

El primer campo contiene el tipo de archivo y los permisos. Los campos siguientes indican el número de enlaces duros, el usuario propietario, el grupo propietario, el tamaño en bytes, la fecha y hora de modificación y el nombre. Este archivo normal pertenece a Priya y al grupo developers. Su tamaño es de 2048 bytes; la fecha y hora mostradas corresponden a la última modificación del contenido.

El primer carácter es - para un archivo normal, d para un directorio o l para un enlace simbólico. También puedes encontrar c y b para dispositivos de caracteres y de bloques, p para una tubería con nombre y s para un socket.

Divide las nueve posiciones siguientes en tres ternas:

En cada terna, las posiciones significan lectura, escritura y ejecución, en ese orden. Un guion indica un permiso ausente, no una posición vacía que debas saltarte al contar.

Elige exactamente una clase

Para una comprobación ordinaria de permisos, Linux pregunta:

1. ¿Coincide el usuario del proceso con el propietario del archivo? Usa la terna del propietario.
2. Si no, ¿coincide alguno de sus grupos con el grupo del archivo? Usa la terna del grupo.
3. En caso contrario, usa la terna de otros.

Las clases no se suman. Supongamos que Priya es propietaria de un archivo cuya cadena completa de tipo y modo es ----rw-rw-. Su terna de propietario es ---, por lo que no puede leerlo mediante los bits ordinarios, aunque el grupo y otros tengan rw-. Como propietaria, puede cambiar el modo. Una terna menos restrictiva para el grupo u otros no sustituye la terna seleccionada del propietario.

Root puede eludir las comprobaciones ordinarias de permisos de lectura y escritura. Para ejecutar un archivo de programa normal, incluso root necesita que tenga al menos un bit de ejecución. Por tanto, comprobar un modo requiere conocer tanto la identidad del usuario como la operación que se intenta realizar.

Inspecciona directorios y números

ls -ld /srv/web lista el propio directorio. Sin -d, ls -l /srv/web normalmente lista las entradas que contiene, lo que puede distraerte de una restricción en el directorio. ls -a incluye nombres ocultos, mientras que ls -n muestra propietarios y grupos numéricos. Los archivos almacenan UID y GID; si se ha eliminado una cuenta o un grupo, un listado ordinario también puede mostrar el número que permanece.

Para obtener un informe compacto, ejecuta:

stat -c '%A %a %U %G %n' report.txt

Puede mostrar -rw-r----- 640 priya developers report.txt, con las letras y los dígitos octales uno al lado del otro. Un + después de las letras indica entradas adicionales de lista de control de acceso. Un enlace simbólico suele mostrar lrwxrwxrwx; Linux usa los permisos del destino para el acceso, no los bits mostrados del enlace.

La lectura, la escritura y la ejecución describen acciones diferentes sobre archivos y directorios. Un directorio almacena nombres que conducen a archivos, por lo que modificar el contenido de un archivo y eliminar su nombre requieren comprobaciones de permisos distintas.

Relaciona el bit con el objeto

Se puede añadir contenido a un archivo con permiso de escritura pero sin permiso de lectura sin leerlo. Por ejemplo, un intérprete puede abrir un registro en el que se puede escribir para echo text >> log.txt aunque cat log.txt falle. Un editor suele necesitar lectura y escritura porque primero carga el contenido existente.

Un guion ejecutado como ./backup.sh necesita permiso de ejecución y debe poder ser leído por su intérprete. Si el guion es legible pero carece de ejecución, bash backup.sh todavía puede leerlo y ejecutarlo: Bash es el programa ejecutable en ese comando.

Distingue entre listar y buscar

El permiso de lectura de un directorio permite ver nombres. El permiso de ejecución, también llamado permiso de búsqueda, permite acceder a una entrada por su nombre. Con lectura pero sin ejecución, ls puede mostrar los nombres, mientras que ls -l no puede obtener sus detalles y puede mostrar errores y signos de interrogación. No puedes abrir los archivos indicados a través de ese directorio.

Con ejecución pero sin lectura ocurre lo contrario: puedes acceder a notes.txt si ya conoces su nombre exacto, pero no puedes listar el directorio para descubrir los nombres. El modo del propio archivo debe permitir el acceso solicitado.

Recorre toda la ruta

Para leer /home/priya/notes/public.txt, Kenji necesita permiso de ejecución en cada directorio de la ruta y permiso de lectura en el archivo. Si /home/priya tiene el modo 700, su terna de otros es ---; Kenji se detiene ahí aunque public.txt tenga el modo 644. Añadir más permiso de lectura al archivo no puede corregir la falta de un bit de búsqueda en un directorio superior.

Usa ls -ld /home/priya /home/priya/notes para inspeccionar los propios directorios. En cada nivel, elige la clase que se aplica a Kenji y comprueba su bit de ejecución. La clase correspondiente puede cambiar de un directorio a otro porque sus propietarios y grupos pueden ser distintos.

Predice la eliminación y el cambio de nombre

Eliminar un archivo elimina una entrada de directorio. Kenji necesita escritura y ejecución en el directorio que lo contiene, no escritura en el archivo. En un directorio ordinario con permiso de escritura y sin bit de permanencia, puede eliminar el archivo de solo lectura de Priya. A la inversa, ser propietario de un archivo no le permite eliminarlo de un directorio donde carece de permiso de escritura.

Quitar la escritura de un archivo es útil para proteger su contenido frente a modificaciones, pero no protege su nombre frente a la eliminación. El bit de permanencia de un directorio añade una restricción basada en la propiedad para eliminar y renombrar en carpetas compartidas con permiso de escritura. El acceso al archivo y el acceso a la entrada de directorio responden a preguntas diferentes.

Usa chmod para cambiar los permisos de un archivo o directorio del que eres propietario. Root también puede cambiarlos. Tener acceso de escritura mediante un grupo te permite modificar el contenido del archivo, pero no te convierte en propietario ni te permite establecer su modo.

Haz un cambio simbólico concreto

Un modo simbólico tiene una clase, un operador y bits. Las clases son u para el propietario, g para el grupo, o para otros y a para las tres. + añade permisos, - los elimina y = establece exactamente los de esa clase.

chmod u+x deploy.sh
chmod go-w notes.txt
chmod u=rw,g=r,o= report.txt

El primer comando añade solo el bit de ejecución del propietario. El segundo elimina la escritura del grupo y de otros y conserva sus demás bits. El tercero da lectura y escritura al propietario, lectura al grupo y ningún permiso a otros: rw-r-----.

Especifica la clase cuando quieras un cambio preciso. Si la omites, como en chmod +w notes.txt, la umask restringe qué bits de clase se ven afectados. Con la umask 022, ese comando añade escritura solo para el propietario; chmod a+w notes.txt incluye explícitamente las tres clases.

Convierte cada terna en un dígito octal

La lectura tiene valor 4, la escritura 2 y la ejecución 1. Suma los valores presentes en cada clase:

Para rw-r-----, divide en rw-, r--, ---: los dígitos son 6, 4, 0. chmod 640 report.txt establece esos nueve bits ordinarios, independientemente del modo ordinario anterior. Invierte el proceso para 750: 7 da rwx, 5 da r-x y 0 da ---, formando rwxr-x---.

Elige un modo final útil

El modo 600 mantiene un archivo privado para su propietario. El modo 644 permite a otros usuarios leer un archivo normal. El modo 664 también permite editar al grupo. Los directorios privados suelen usar 700, los directorios legibles por el grupo 750 y los directorios en los que el grupo puede escribir 770. Los programas o directorios públicos suelen usar 755.

Los mismos dígitos permiten acciones útiles distintas según el objeto. Aplicar 644 a un directorio quita la ejecución a todas las clases. Ni siquiera su propietario puede volver a entrar en él ni abrir archivos a través de él. Usa un modo de directorio con permiso de búsqueda para las personas que necesitan acceso.

Aplica cambios a todo un árbol

chmod -R 755 site/ también hace ejecutables todos los archivos normales. Para un árbol que contiene directorios y documentos normales, usa la ejecución condicional:

chmod -R u=rwX,go=rX site/

La X mayúscula añade ejecución a los directorios y a los archivos que ya tienen algún bit de ejecución. Los archivos no ejecutables pasan a 644; los directorios pasan a 755. Los archivos ejecutables existentes conservan el acceso de ejecución. Esto permite recorrer el árbol sin marcar cada documento como programa. Los bits especiales son independientes: GNU chmod conserva SUID y SGID en los directorios a menos que los desactives explícitamente, por ejemplo con chmod g-s site/.

La propiedad identifica al usuario y al grupo cuyas ternas de permisos se comprobarán. Una propiedad correcta puede arreglar una carpeta de trabajo creada accidentalmente con sudo, sin conceder un acceso más amplio a todos los demás.

Interpreta las formas de chown

chown puede cambiar un usuario, un grupo o ambos:

Los identificadores numéricos también funcionan, como en sudo chown 1002:1005 report.txt. Los nombres se resuelven en números; el archivo almacena esos números.

Solo root puede transferir un archivo a otro usuario propietario. Un propietario puede cambiar el grupo de su propio archivo a uno al que pertenezca. Así, Priya puede usar chgrp webteam plan.txt si es propietaria del archivo y pertenece a webteam. Para asignarlo a finance también tendría que pertenecer a ese grupo. Que otro miembro pueda editar el archivo no le concede la capacidad de cambiar su propietario o modo.

Repara una carpeta creada accidentalmente como propiedad de root

Kenji ejecutó un comando de creación con sudo. El listado es:

drwxr-xr-x 2 root root 4096 Oct 22 10:02 /home/kenji/app

No es el propietario ni utiliza el grupo propietario, por lo que recibe el r-x de otros. Puede inspeccionar la carpeta y entrar en ella, pero no puede crear entradas porque falta la escritura. Dar permiso de escritura en la carpeta a todos concedería más acceso del que necesita su proyecto.

Si el proyecto pertenece a Kenji, sudo chown -R kenji: ~/app restablece su propiedad y su grupo de inicio de sesión en toda la carpeta. Su terna de propietario es ahora rwx, por lo que puede crear archivos. Inspecciona la ruta de destino antes de cualquier comando recursivo de cambio de propiedad: aplicarlo a /etc o /usr puede impedir el funcionamiento del sistema. -R incluye el directorio y todo lo que hay por debajo.

Predice la propiedad después de operaciones con archivos

Un archivo recién creado pertenece al usuario del proceso que lo crea. Su grupo suele proceder del grupo principal de ese proceso o de un directorio padre con SGID. Por tanto, crear una copia nueva ordinaria con cp hace que quien lo ejecuta sea su propietario. Un mv dentro del mismo sistema de archivos cambia la ubicación de un archivo existente y conserva su propietario y grupo. Las opciones de copia que conservan la propiedad tienen un comportamiento distinto al de una copia nueva ordinaria.

Esta distinción explica por qué mover un archivo antiguo a una carpeta compartida no le aplica la regla de herencia de grupo de esa carpeta. SGID se aplica en el momento de la creación; usa chgrp cuando haya que cambiar el grupo de un archivo existente.

Combina identidad y acceso

Asignar webteam con chgrp selecciona a quién representa la clase de grupo. No añade lectura ni escritura al grupo. Usa chmod para conceder los bits necesarios después de elegir el grupo. Cambiar la propiedad de un ejecutable también puede desactivar los privilegios SUID o SGID; inspecciona su modo resultante cuando esos bits importen.

Los permisos de un archivo nuevo proceden de dos valores: el modo que solicita el programa que lo crea y la umask del proceso. La máscara elimina bits solicitados; nunca añade permisos que el programa no haya pedido.

Empieza por la solicitud de creación

Los editores y la redirección del intérprete suelen solicitar 666, o rw-rw-rw-, para archivos normales nuevos. La creación de directorios suele solicitar 777, o rwxrwxrwx. Una umask es un conjunto de bits que se desactivan de esa solicitud. Un bit se conserva solo cuando la solicitud lo incluye y la máscara no.

Para la umask 022, conserva todos los bits solicitados del propietario, elimina la escritura del grupo y elimina la escritura de otros. Un archivo pasa a 644; un directorio pasa a 755. Interpreta cada dígito como bits, no como una cantidad decimal ordinaria.

Con 027, el grupo pierde la escritura mientras que otros pierden los tres bits. Es útil cuando un equipo debe leer los archivos nuevos, pero los usuarios ajenos al equipo no deben tener acceso. Con 002, la escritura del grupo permanece disponible; el grupo propietario del archivo sigue determinando quién la recibe.

Por qué falla la resta

Toma la solicitud de archivo 666 y la máscara 033. Cada 3 significa escritura más ejecución. Pero cada terna solicitada para el archivo es rw-: la ejecución ya está ausente. Desactivar escritura y ejecución deja r-- para el grupo y otros, por lo que el resultado es 644. Restar los dígitos produciría 633, lo que sugeriría erróneamente que pueden aparecer bits de ejecución.

Para una solicitud de directorio de 777, desactivar esos mismos bits da 744. Ese directorio carece de ejecución para el grupo y otros, por lo que esas clases no pueden acceder a sus entradas aunque puedan listar los nombres. Una máscara que da el modo de archivo deseado puede producir un resultado inconveniente para los directorios.

Consulta y establece tu máscara

Ejecuta umask para ver el ajuste actual, que a menudo se muestra con un cero inicial, como 0022. El cero inicial es parte del formato; Linux utiliza los nueve bits de permisos ordinarios. umask -S muestra los bits permitidos, como u=rwx,g=rx,o=rx para 022; un programa puede solicitar un subconjunto de esos bits.

umask 027 cambia el intérprete actual y los programas que este inicia heredan el valor. Los archivos existentes conservan sus modos. Usa chmod cuando un archivo ya creado necesite permisos diferentes.

Elige un valor predeterminado persistente

Una línea como umask 027 en ~/.profile o ~/.bashrc puede establecer el valor para los intérpretes que leen ese archivo de inicio. Los valores predeterminados del sistema pueden proceder de /etc/profile o de UMASK en /etc/login.defs. La distribución y la configuración de la cuenta determinan qué archivos se leen y cuándo.

Muchos sistemas usan 022, mientras que las configuraciones con grupos privados suelen usar 002 para los usuarios normales. Un compilador puede solicitar una salida ejecutable con el modo 777; con 022 pasa a 755. La solicitud de 666 de un editor de texto no tiene bits de ejecución, por lo que escribir un guion no lo hace ejecutable por sí mismo.

Tres bits especiales añaden comportamientos a los permisos ordinarios de propietario, grupo y otros. Su significado depende de si el objeto es un programa o un directorio.

Reconoce el dígito adicional

Un dígito octal inicial combina SUID 4, SGID 2 y el bit de permanencia 1. El modo 4755 es SUID más el modo ordinario 755. El modo 2770 es SGID más 770. El modo 3770 combina SGID y el bit de permanencia porque 2 más 1 es 3.

En un listado en formato largo, los bits comparten las posiciones de ejecución. Una s minúscula en la posición del propietario significa SUID y ejecución del propietario; una s minúscula en la posición del grupo significa SGID y ejecución del grupo. Una t minúscula en la posición de otros significa bit de permanencia y ejecución de otros. Una S o T mayúscula significa que el bit especial está presente, pero falta la ejecución en esa posición.

SUID y SGID en programas

SUID permite que un ejecutable se ejecute con la identidad efectiva del propietario del archivo. /usr/bin/passwd suele aparecer como -rwsr-xr-x root root: el programa puede actualizar los datos protegidos de contraseñas mientras controla qué contraseña de usuario puede cambiar quien lo ejecuta. Iniciarlo no da a esa persona un intérprete de root. Linux ignora SUID en guiones y directorios.

SGID en un ejecutable utiliza de forma similar la identidad de grupo del archivo. Estos bits conceden acceso controlado por el programa, por lo que importa su comportamiento. Nunca añadas SUID a un intérprete de comandos, un editor o un guion. Un administrador puede inventariar archivos normales con SUID mediante sudo find / -perm -4000 -type f 2>/dev/null; usa -perm -2000 para archivos SGID y compara los resultados con la configuración prevista del sistema.

SGID en un directorio de equipo

En un directorio, SGID hace que las entradas nuevas adopten el grupo del directorio y que los subdirectorios nuevos hereden SGID. Supongamos que /srv/web pertenece a root:webteam, tiene el modo 2770 y se muestra como drwxrws---. Priya tiene un grupo principal privado, pero pertenece a webteam. Cuando crea index.html dentro de este directorio, su grupo pasa a ser webteam.

Su modo ordinario sigue dependiendo de la creación. Con una solicitud de archivo de 666 y la umask 002, pasa a 664 y Kenji, otro miembro del equipo, puede editarlo. Con 022 pasa a 644, por lo que Kenji solo tiene acceso de lectura. SGID proporciona el grupo, no un bit de escritura adicional.

Directorios con bit de permanencia y eliminación

El bit de permanencia restringe la eliminación y el cambio de nombre: con el acceso necesario al directorio, una entrada puede ser eliminada por el propietario del archivo, el propietario del directorio o root. Esto hace que los directorios compartidos con permiso de escritura sean útiles sin permitir que los usuarios eliminen las entradas de los demás. /tmp y /var/tmp suelen usar 1777, que se muestra como drwxrwxrwt. El bit de permanencia no impide editar el contenido de los archivos cuando su modo lo permite. Linux lo ignora en archivos normales.

Establece los bits con chmod u+s prog, chmod g+s /srv/web o chmod o+t /srv/drop. Desactívalos con u-s, g-s u o-t. Con GNU chmod, chmod 755 /srv/web conserva un bit SGID existente en el directorio; usa chmod g-s /srv/web para desactivarlo explícitamente.

Un error «Permiso denegado» identifica una operación fallida, pero no necesariamente un modo de archivo incorrecto. El bloqueo puede estar en los grupos de tu sesión, un directorio padre, el propio archivo o la propiedad dejada por un comando con privilegios elevados.

Sigue la identidad, la ruta, la clase y la operación

Empieza con id sin argumentos en la sesión afectada. Si se añadió un grupo recientemente, compara la lista activa con id username, que consulta la base de datos. Un nuevo inicio de sesión puede cargar la nueva pertenencia.

Después inspecciona toda la ruta:

namei -l /srv/reports/q3.txt

namei -l informa de los propietarios, grupos y modos de la ruta. También puedes inspeccionar cada directorio con ls -ld. En cada objeto, selecciona la primera clase que coincida: propietario, si no grupo y, en caso contrario, otros. Después pregunta qué necesita la operación que se intenta realizar. Leer requiere r en el archivo y permiso de búsqueda en todos los directorios padre. Crear, eliminar o renombrar una entrada requiere w y x en su directorio, con las restricciones del bit de permanencia cuando esté presente.

Encuentra la primera operación bloqueada

Kenji pertenece a finance e intenta ejecutar cat /srv/reports/q3.txt. Los objetos relevantes son:

drwxr-xr-x root  root     /srv
drwxr-x--- root  finance  /srv/reports
-rw------- maria finance  /srv/reports/q3.txt

Kenji puede atravesar /srv usando la ejecución de otros. En /srv/reports, su pertenencia a finance selecciona el r-x del grupo, por lo que también puede atravesarlo. En q3.txt, no es Maria y la terna de finance es ---. El permiso que falta es la lectura del grupo en el archivo.

Si los miembros de finance deben leer el informe, Maria o root pueden ejecutar chmod g+r /srv/reports/q3.txt. El modo resultante es 640. Proporciona el permiso que falta sin dar escritura al grupo ni abrir el informe a otros. Un administrador puede probarlo con sudo -u kenji cat /srv/reports/q3.txt, ejecutando el comando como Kenji en lugar de probarlo como root.

Elige la corrección más pequeña

Una corrección adecuada puede consistir en añadir a alguien a un equipo, establecer lectura para el grupo, restablecer el propietario de un proyecto o añadir búsqueda en un directorio para la clase prevista. chmod -R 777 concede a todas las cuentas locales acceso de escritura en todo el árbol y hace ejecutables los archivos normales. Tampoco puede resolver todas las causas de un fallo de acceso.

Comprueba las causas habituales antes de editar un árbol grande: una nueva pertenencia inactiva, la falta de x en un directorio padre, trabajo propiedad de root creado con sudo y archivos nuevos cuya umask eliminó el acceso necesario para el equipo. Las unidades FAT32 y exFAT no almacenan UID, GID ni modos nativos de Linux; las opciones de montaje proporcionan esos valores, por lo que chmod o chown aplicados a cada archivo pueden fallar o no tener efecto.

Mantén privados los datos privados

Una clave privada SSH como ~/.ssh/id_ed25519 normalmente debe tener el modo 600; su directorio .ssh suele tener 700. SSH comprueba la protección de la clave privada y puede rechazar una clave demasiado accesible. /etc/shadow sigue siendo inaccesible para los usuarios normales. Los administradores con permisos completos de sudo pueden eludir la privacidad ordinaria de los archivos, así que mantén reducido ese grupo y concede acciones específicas cuando no sea necesaria la administración completa.