Módulo 5 - Gestión de Usuarios y Permisos en Linux

usuarios

Temas incluidos:

Usuarios y grupos en Linux: concepto de cuentas, UID/GID
El usuario root vs usuarios regulares; principio de mínimo privilegio
Comandos para administrar usuarios y grupos (useradd, passwd, usermod, groupadd, etc.)
Estructura de archivos de cuentas: /etc/passwd, /etc/shadow, /etc/group
Permisos de archivos: propietario, grupo, otros (r, w, x) y cómo interpretarlos
Cambiar permisos y propietarios (chmod, chown, chgrp); modos numéricos y simbólicos
Uso de sudo y su para tareas administrativas
Errores comunes de permisos y cómo solucionarlos

Usuarios y grupos en Linux; cuentas y roles

Concepto desarrollado: Linux es un sistema multiusuario, lo que significa que múltiples cuentas pueden existir (y operar simultáneamente) en el mismo sistema, con permisos diferenciados. Cada cuenta de usuario tiene un identificador numérico único llamado UID (User ID), y pertenece a uno o varios grupos que tienen identificadores GID (Group ID). Las cuentas se definen principalmente en el archivo de texto /etc/passwd (aunque las contraseñas en sí están en /etc/shadow cifradas). Los grupos se definen en /etc/group.

root es el usuario administrador supremo (UID 0). Tiene permisos completos sobre el sistema – puede leer, modificar, ejecutar y borrar cualquier archivo, configurar cualquier cosa. Por su poder, trabajar directamente como root es peligroso si no se sabe bien lo que se hace; por eso, la buena práctica es usar un usuario normal para las tareas cotidianas y solo elevar privilegios cuando sea necesario, usando sudo o cambiando temporalmente a root con su.

Los usuarios “regulares” suelen tener UID empezando desde 1000 (esto varía por distro; en CentOS/RHEL típicamente el primer usuario creado tiene UID 1000). Los IDs mayores a 1000 a menudo están reservados para usuarios del sistema (cuentas de servicios, como apache para el servidor web, mysql para la base de datos, etc., que no son personas sino cuentas usadas por demonios).

Cada usuario tiene un grupo principal (generalmente uno con su mismo nombre) y puede pertenecer a grupos secundarios adicionales. Los grupos sirven para otorgar permisos compartidos a conjuntos de usuarios (por ejemplo, grupo “developers” que tiene acceso a cierto directorio). Un usuario puede cambiar temporalmente de identidad usando su (substitute user) para actuar como otro usuario (necesitas su contraseña, a menos que seas root), o usar sudo para ejecutar un solo comando como root (necesitas estar autorizado en /etc/sudoers para eso, típicamente miembros del grupo wheel en CentOS).

Comandos esenciales y sintaxis (usuarios/grupos):

id: muestra tu UID, GID y grupos actuales. Útil para verificar qué permisos podrías tener.
useradd nombre: crea un nuevo usuario. En CentOS, por defecto:
- Crea la entrada en /etc/passwd, /etc/shadow.
- No asigna contraseña (la cuenta está bloqueada hasta que se use passwd).
- Crea el directorio home /home/nombre (a menos que se use -M para evitarlo) y copia archivos de /etc/skel (plantillas).
- Asigna un shell por defecto (tipicamente /bin/bash) y un grupo principal del mismo nombre.
- Opciones: -m (asegurar que cree home), -c "Comentario" para nombre descriptivo, -G grupo1,grupo2 para grupos secundarios, -s /bin/nologin para usuarios sin shell, etc.
passwd nombre: asigna o cambia la contraseña de nombre. Si lo ejecutas solo como passwd (sin usuario) cambiará la tuya propia. Como admin, passwd usuario define la del usuario (y puedes usar --stdin para pasarla vía input, o usar chpasswd).
userdel nombre: elimina una cuenta. Opciones: -r para borrar su home y correo (correspondiente a /var/spool/mail). Sin -r, deja sus archivos intactos (pero ya sin dueño referenciado, aparecen con UID en ls).
usermod: modifica una cuenta existente. Ej: usermod -aG wheel usuario lo agrega al grupo wheel (la -a es importante al usar -G, sin -a reemplazaría grupos en lugar de añadir). O usermod -L usuario bloquea la cuenta (lock, antepone ! a su hash en /etc/shadow).
groupadd grpname: crea un nuevo grupo. groupdel grpname lo elimina (solo si ningún usuario pertenece ya, o hay que quitarlo antes).
gpasswd -a usuario grpname: añade un usuario a un grupo (alternativa a usermod -aG).
su - usuario: cambia al usuario dado solicitando su contraseña. su - sin nombre implica root (requiere conocer la pass de root). El - (guión) asegura que cargas el entorno como si ese usuario hubiera hecho login (cambias a su home, aplicas su perfil).
sudo comando: intenta ejecutar comando como root (u otro usuario si se especifica con -u). Pedirá la contraseña del usuario actual, no la de root (contrario a su). Requiere que tu usuario esté en el archivo sudoers con permisos. En CentOS, el grupo wheel suele tener permiso de ALL vía sudo (ver /etc/sudoers). Por eso añadimos nuestro usuario a wheel en módulo 1.
visudo: abre el archivo sudoers con comprobación de sintaxis para editar los permisos de sudo. Usar con cuidado. Este utiliza vi por defecto.

🧪 Ejercicio práctico paso a paso:

Crear un usuario nuevo: Como root (o usando sudo), ejecuta useradd prueba1. Esto creó la cuenta prueba1. Ahora asígnale contraseña: passwd prueba1. El sistema te pedirá escribir la nueva contraseña (y confirmarla). Úsala simple para pruebas (p.ej. "Temporal123", aunque en producción debe ser segura). Verás mensaje de success si todo bien.
Verificar info de la cuenta: Abre /etc/passwd con grep prueba1 /etc/passwd. Debería mostrar algo como prueba1:x:1001:1001::/home/prueba1:/bin/bash. Esto indica: nombre, x (porque la pass está en shadow), UID 1001, GID 1001, comentario vacío, home, shell. Mira /etc/shadow con sudo grep prueba1 /etc/shadow (solo root puede leerlo). Verás prueba1:!<hash largo>... El ! indica que la cuenta estaba bloqueada hasta que definiste pass; tras passwd, verás en lugar de ! un hash cifrado (no lo entenderás, es irreversible).
Crear grupo y agregar usuario: sudo groupadd devs crea un grupo devs. Ahora sudo usermod -aG devs prueba1 añade prueba1 a ese grupo secundario. Verifícalo con id prueba1 (ejecuta id prueba1 como root o con sudo -u prueba1 id para ver los grupos, debería listar devs). Alternativamente, mira /etc/group con grep devs /etc/group para ver si aparece prueba1 en la lista de miembros.
Probar su y sudo: Usa su - prueba1 e ingresa la contraseña de prueba1. Notarás que ahora tu prompt cambia indicando que eres ese usuario (y tu directorio actual será /home/prueba1). Intenta ejecutar cd /root luego ls; debería negar permiso porque ahora eres un usuario normal. Sal de su con exit o Ctrl+D, vuelves a tu usuario anterior. Ahora intenta sudo -i (si estás en tu usuario sudoer). sudo -i te da un shell de root (pidiendo tu pass). Deberías ver prompt de root (#). Es equivalente a su - pero usando tu poder sudo. Sal con exit.
Eliminar usuario (opcional, cuidado): Si quieres limpiar lo creado, puedes hacer sudo userdel -r prueba1. Con -r borrará /home/prueba1 también. Verifica luego que grep prueba1 /etc/passwd no encuentra nada. Nota: no borres usuarios del sistema ni tu usuario principal; solo los de prueba que creaste.
Bloquear/Desbloquear cuenta: Crea de nuevo useradd prueba2 y passwd prueba2. Ahora bloquea con usermod -L prueba2. Si haces sudo grep prueba2 /etc/shadow, verás un ! añadido al inicio del hash, eso bloquea login. Intenta su - prueba2 con su contraseña, no te dejará entrar (autenticación fallida). Desbloquea con usermod -U prueba2. Ahora su - prueba2 funcionará con su password.
Explorar info de usuarios existentes: Usa comandos como getent passwd root (te muestra la línea de passwd de root) o simplemente less /etc/passwd para ver todos. Observa que muchos usuarios de sistema (UID bajos, sin shell o con /sbin/nologin, y sin home o con /) existen. Estos no se usan para login humano, sino para servicios. Ej: usuario apache suele correr el servidor web, etc. Comprender que no todos los “usuarios” en /etc/passwd representan personas.

Puntos clave a recordar:

Cada proceso en Linux se ejecuta con los permisos de algún usuario. Por eso, las cuentas de sistema aíslan servicios (ej., si alguien hackea el servicio web que corre como usuario apache, solo tendrá permisos limitados de ese usuario, protegiendo el resto del sistema).
Contraseñas: Al asignar con passwd, se almacenan cifradas en /etc/shadow con algoritmos hash (ej. SHA-512). Nunca se guardan en texto plano. shadow solo es legible por root, a diferencia de passwd que es público (pero allí solo figura 'x' en lugar de la contraseña desde hace décadas por seguridad).
La política de sudoers en CentOS: miembros del grupo wheel pueden sudo (ver /etc/sudoers, línea %wheel ALL=(ALL) ALL). Por eso agregamos usuario a wheel para que tenga privilegios de administrador sin ser root siempre. No se recomienda usar root directamente salvo emergencias; sudo registra acciones (en /var/log/secure) y puedes configurar qué se permite.
UIDs y GIDs: puedes especificar al crear un usuario un UID/GID concreto con -u y -g, pero si no, se asigna el siguiente libre. Es bueno dejar que el sistema gestione esos números a menos que necesites consistencia entre sistemas (NFS shares, etc. podrían requerir alinear UIDs).
(Imagen sugerida: un esquema ilustrando usuarios y grupos: por ejemplo, un diagrama con varios usuarios (como iconos de personas) mostrando que pertenecen a ciertos grupos (círculos), y cómo uno de ellos es root con acceso completo. También quizá un pantallazo de id mostrando UID, GID y grupos para visualizar la pertenencia. Esto puede clarificar la relación usuario-grupo-permisos.)**
Diferencia entre su y sudo: su inicia un shell como otro usuario (necesitas su password), sudo ejecuta un comando como otro usuario (por defecto root) usando tu propia autenticación si estás autorizado. sudo -i o sudo su - efectivamente te dan shell root. Importante: con sudo se puede delegar privilegios por comando, loguear acciones y sin compartir la contraseña de root a usuarios. Con su, si das la contraseña de root a alguien, tiene full control sin registro. Por eso sudo es preferible en entornos multi-admin.
Archivos skeleton: Lo que aparece en un nuevo home (como .bash_profile, .bashrc, etc.) viene de /etc/skel. Puedes personalizar /etc/skel para preconfigurar cosas para nuevos usuarios.

Errores comunes y cómo evitarlos:

Olvidar -a en usermod -G: Si quieres añadir un usuario a un nuevo grupo y usas usermod -G nuevo grupo usuario sin -a, eliminarás todos sus grupos secundarios previos, dejándolo solo en el nuevo (además de su principal). Esto es un error típico y puede causar que pierda acceso a cosas. Siempre usar -aG para agregar sin quitar.
No asignar contraseña al crear usuario: Tras useradd, la cuenta no tiene contraseña (o está bloqueada). Si creas un usuario y le dices a alguien "entra con usuario X", no podrá hasta hacer passwd. Alternativa: usar useradd -p con un hash ya generado o chpasswd. Pero en simple, recuerda correr passwd.
Borrar un usuario y perder archivos: Si eliminas un usuario sin -r, su home queda. Los archivos que eran de él ahora al listar muestran el UID en vez de nombre (porque ya no hay nombre asociado). Es fácil olvidarse de borrar esos archivos huérfanos. Siempre que borres un usuario, considera si necesitas sus archivos; si no, usa -r. Si sí, transfierelos a otro usuario (chown -R nuevo:nuevo /home/viejo antes de borrarlo, por ejemplo).
Editar /etc/sudoers incorrectamente: Añadir mal una línea en sudoers puede dejarte sin privilegios sudo (si hay error de sintaxis, sudo dejará de funcionar). Por eso se usa visudo que valida. Error típico: quitar el Defaults requiretty en algunas distros viejas, o poner un alias mal. Siempre valida y de preferencia no borres reglas existentes, añade nuevas líneas con formato correcto.
Conceder permisos root en exceso: Por comodidad, hay quien pone usuario ALL=(ALL) NOPASSWD:ALL en sudoers (sin requerir pass). Esto da acceso total sin control. Evitar en lo posible; mejor pedir pass, y si se va a no pedir, delimitar comandos permitidos en lugar de ALL (ej, solo permitir systemctl o ciertas rutas).
No ajustar /etc/login.defs y políticas: No tanto error de un admin novel, pero notar: por defecto useradd en CentOS puede crear usuarios con 99999 días de validez de password (prácticamente nunca expira), etc. Para entornos corporativos quizás requieras que expiren cada X días, bloqueo tras intentos fallidos (eso se hace con PAM, faillock), etc. No cubrirá este curso, pero sepa que useradd toma configuraciones de /etc/default/useradd y /etc/login.defs.

Tips de rescate si algo falla:

Recuperar acceso root si lo pierdes: Si olvidas la pass de root o te quedas sin sudo funcional (p.ej. editaste mal sudoers), puedes reiniciar el sistema en modo monousuario (single user mode) o rescue mode desde GRUB. Ahí entras como root sin contraseña (en muchas configuraciones) y puedes resetear la pass con passwd root o corregir sudoers. Asegúrate de tener acceso al entorno físico o consola virtual para esto.
Agregar sudo a un usuario sin editar sudoers: En CentOS, basta con usermod -aG wheel usuario. Porque wheel ya está en sudoers. Así evitas tocar el archivo manualmente. Esto lo hicimos con estudiante al inicio.
Comandos de “expiración” y info de cuentas: chage -l usuario muestra la info de expiración de contraseña (días para cambio, etc.). faillock --user usuario --reset resetea bloqueos de login tras intentos fallidos (PAM). Solo para notar que hay más utilidades alrededor de usuarios.
Skell custom y auto scripts: Puedes hacer que al crear usuarios se ejecuten ciertos scripts (usando /etc/skel para dotfiles con logic, o PAM modules). Por ejemplo, empresas que integran nuevos empleados podrían crear plantillas para que al primer login, un script de bienvenida corra. Excede este curso, pero interesante de explorar.
Grupos especiales: Algunos grupos en Linux tienen significados especiales. Ej: grupo wheel ya vimos, grupo sudo en Debian cumple lo mismo. Grupo adm a veces permite leer logs en /var/log. Grupo docker da permiso a manejar docker sin sudo (pero es root-equivalente). Grupo tty y otros raros suelen ser del sistema. Infórmate antes de añadir usuarios a grupos a ciegas, solo para roles necesarios.
Eliminar procesos de usuarios borrados: Si borras un usuario que tenía procesos corriendo, esos procesos seguirán con su UID (ahora sin nombre) hasta que terminen o se mate. Puedes identificar procesos de un UID con ps -u <UID> y decidir qué hacer. Normalmente, al borrar cuentas humanas, se hace cuando no están logueadas; pero para cuentas de servicio, cuidado, mejor detener el servicio primero.

Criterios de evaluación del módulo:

✅ El alumno entiende la diferencia entre usuario root y usuarios normales, y puede explicar por qué no es seguro operar siempre como root.

✅ Es capaz de crear, modificar y eliminar usuarios y grupos usando los comandos apropiados, y verifica los resultados consultando los archivos de sistema (/etc/passwd, /etc/group, etc.).

✅ Sabe establecer y cambiar contraseñas de usuarios, así como bloquear/desbloquear cuentas, administrando accesos de forma básica.

✅ Comprende la utilidad de los grupos, demostrando cómo asignar un usuario a grupos secundarios para otorgarle ciertos permisos (por ejemplo, añadirse a wheel para sudo).

✅ Utiliza correctamente sudo para tareas administrativas, confirmando que su usuario está autorizado, y entiende cómo usar su para cambiar de identidad cuando sea necesario, manteniendo buenas prácticas de seguridad (no compartiendo contraseñas de root innecesariamente).

❓ Preguntas de repaso recomendadas:

¿Dónde se almacenan los hashes de las contraseñas de usuarios en Linux y quién puede leerlos?
¿Qué comando utilizarías para agregar a un usuario existente al grupo "developers" sin quitarlo de otros grupos? ¿Y cómo verificarías luego que está en dicho grupo?
Explica con tus palabras por qué es mejor dar acceso sudo a un usuario que darle la contraseña de root directamente.
Si al intentar usar sudo te sale un mensaje "user is not in the sudoers file", ¿qué pasos seguirías para corregirlo?
Creaste un usuario y ves que en /etc/passwd su shell es /sbin/nologin. ¿Qué significa eso y cuándo sería útil tener un usuario con nologin como shell?

Requisitos previos al módulo:

Acceso administrativo (ya sea como root o con un usuario con sudo) en el sistema CentOS Stream 9 para poder crear/editar cuentas.
Idealmente, un entorno de pruebas donde crear usuarios no afecte a otros (hacerlo en una VM o contenedor aislado es lo mejor; en un servidor de producción real, crear y borrar usuarios de prueba no es recomendable).
Conocer bien cómo abrir una root shell o usar sudo, y navegar por archivos de sistema. También tener instalado un editor (nano o usar vi) en caso de querer inspeccionar manualmente los archivos de configuración como /etc/passwd.
Conocimientos de módulos previos: manejo de archivos (la home que se crea es un directorio con permisos, etc.), uso de grep/cat para ver archivos de texto (útil para ver /etc/passwd), etc.

Permisos de archivos y directorios: r, w, x para usuario, grupo, otros

Concepto desarrollado: Cada archivo y directorio en Linux tiene asociado un propietario (user), un grupo, y un conjunto de permisos que determinan qué puede hacer el dueño (user), el grupo asignado, y otros (todos los demás). Los permisos básicos se definen en tres bits: r (read), w (write), x (execute). Para archivos, r=leer el contenido, w=modificar el contenido, x=ejecutarlo como programa/script. Para directorios, r= listar su contenido, w= crear o borrar elementos dentro (modificar estructura), x= atravesarlo (poder ingresar, es decir cd a él, y acceder a elementos si se conoce el nombre).

Cuando haces ls -l, los primeros 10 caracteres indican tipo y permisos: por ejemplo -rw-r--r--:

El primer carácter es tipo (- archivo, d directorio, l enlace, etc.).
Luego vienen 3 caracteres de permisos del dueño (propietario).
Luego 3 para el grupo.
Luego 3 para otros (también llamados "world").

En -rw-r--r--, podemos segmentar:

Propietario: rw- (read+write, sin execute)
Grupo: r-- (read, sin write ni exec)
Otros: r-- (lo mismo que grupo en este caso)

Esto típicamente indica un archivo de texto donde el dueño puede leer y modificar, pero todos los demás solo pueden leerlo.

Otro ejemplo: drwxr-x--- podría ser un directorio donde:

d = directorio.
Dueño: rwx = puede listar (r), modificar contenidos (w), entrar (x) – básicamente control total en su dir.
Grupo: r-x = miembros del grupo pueden listar (r) y entrar (x), pero no crear/borrar cosas (no w).
Otros: --- = nadie más tiene acceso alguno.

Además de estos 9 bits básicos, existen los bits especiales: suid, sgid, sticky. A nivel introductorio:

suid (Set UID): en archivos ejecutables, hace que si alguien lo ejecuta, el proceso corre con el UID del dueño del archivo, no del usuario que lo corre. Representado con s en lugar de x en la posición de propietario (ej: -rwsr-xr-x). Un ejemplo clásico es /bin/passwd que tiene suid para que un usuario normal al ejecutarlo pueda cambiar contraseñas (requiere elevación a root internamente).
sgid (Set GID): similar, pero con GID. En ejecutables, fuerza a correr con grupo del archivo; en directorios, hace que archivos creados dentro hereden el grupo del directorio, no el principal del usuario. Aparece como s en posición de grupo (ej: rwxr-sr-x). Directorios sgid son útiles para carpetas colaborativas.
sticky bit: relevante en directorios como /tmp. Representado con t en lugar de x en "otros" (ej: rwxrwxrwt). Significa que aunque el dir sea writeable por todos, solo el dueño de un archivo (o root) puede borrarlo. Evita que en /tmp alguien borre archivos de otro. En archivos regulares, sticky ya no tiene uso práctico salvo en binarios antiguos de sistemas Unix (caché en swap, no importa hoy).
Para no alargar, estos bits especiales son más avanzados, pero debes reconocer la s o t si aparecen en listados.

Comandos esenciales y sintaxis (permisos):

chmod: cambia permisos.
- Modo octal: cada tripleta rwx corresponde a un número en base 8 (r=4, w=2, x=1 sumados). Ej: rwx = 7, rw- = 6, r-x =5, r-- =4, etc. Entonces chmod 640 archivo asigna permisos rw- r-- --- (6=rw-,4=r--,0=---).
- Modo simbólico: especificas quién y qué quitar/poner. Ej: chmod u+x script.sh añade permiso de ejecución al usuario dueño (u). chmod go-w archivo quita permiso de escritura a grupo y otros. chmod a+r file da lectura a todos (a = all).
- Para setuid, sgid, sticky via octal: se antepone un dígito extra al número de permisos normal (es decir 4XYZ para setuid, 2XYZ para sgid, 1XYZ for sticky, y combinados sumas: 7 = 4+2+1 sets all). Simbólico: chmod u+s archivo (setuid), chmod g+s dir (sgid), chmod o+t dir (sticky).
chown usuario:grupo archivo: cambia propietario y grupo de un archivo. Ej: sudo chown root:root /datos asigna root como dueño y grupo root. Puedes usar chown usuario archivo (solo cambia usuario, mantiene grupo) o chown :grupo archivo para solo grupo.
- Añadir -R para hacer recursivo en un directorio (cambiar dueño/grupo de todo dentro).
chgrp grupo archivo: cambia solo el grupo.
umask: máscara de permisos por defecto al crear archivos. Por ejemplo, si umask es 0022, típicamente nuevos archivos se crean 644 y dirs 755 (básicamente restando umask de permisos totales). Esto dicta permisos iniciales.
stat archivo: muestra detalles de un archivo, incluyendo propietario, grupo, permisos en octal (nice to have) y tiempos.
namei -l /ruta/archivo: herramienta útil para debug, descompone la ruta y muestra permisos en cada nivel, para ver dónde puede estar un problema de permisos.

🧪 Ejercicio práctico paso a paso:

Inspeccionar permisos con ls: Ve a tu directorio de proyectos o home y ejecuta ls -l. Toma una línea y analiza los 10 caracteres. Identifica el tipo (archivo o dir) y los permisos de cada categoría. Por ejemplo, si ves -rw-rw-r--. 1 estudiante estudiante 1024 Jan 1 12:00 notas.txt:
- - = archivo normal.
- rw- (u) = estudiante puede leer y escribir.
- rw- (g) = grupo estudiante (grupo principal con mismo nombre) puede leer y escribir también.
- r-- (o) = otros solo leen.
- Observa también el número 1 (enlaces duros), owner, group, size, date, name.
Cambiar permisos simple: Crea un archivo echo "secreto" > secreto.txt. Por defecto, probablemente tenga 664 (rw-rw-r--, dependiendo de umask). Queremos que solo tú puedas leerlo y editarlo, nadie más. Haz chmod 600 secreto.txt. Comprueba con ls -l: debería quedar -rw-------. Ahora, intenta leerlo con tu usuario (cat funciona). Si tuvieras otro usuario logueado, ese no podría cat secreto.txt (prueba con sudo -u prueba1 cat secreto.txt si aún tienes a prueba1; debería decir "Permission denied").
Hacer un script ejecutable: Crea un script simple: echo -e "#!/bin/bash\necho Hola" > hola.sh. Ahora ls -l hola.sh verá -rw-rw-r--. Para ejecutarlo (./hola.sh), necesitas x. Añade ejecución solo para ti: chmod u+x hola.sh. Ahora ls -l debería mostrar -rwxrw-r--. Prueba ejecutarlo: ./hola.sh debería imprimir Hola. Si otro usuario intenta ejecutarlo, no podrá porque no tiene x para grupo/otros (tendrían "permission denied" ejecutando, aunque podrían leer el contenido con r).
Crear directorio colaborativo: Como root, crea una carpeta de proyecto: sudo mkdir /proyecto. sudo chown :devs /proyecto para asignar el grupo "devs" (que creamos antes) como grupo dueño, y sudo chmod 2775 /proyecto. ¿Qué hicimos? 2775 en permisos: el 2 inicial pone sgid en el directorio, 7 = rwx para owner (root), 7 = rwx para group (devs), 5 = r-x para otros. sgid hará que archivos creados dentro tengan grupo devs automáticamente. Ahora, si tú (miembro de devs) creas algo ahí, comprueba que el grupo es devs. Por ejemplo: sudo touch /proyecto/prueba.txt (usando sudo porque /proyecto es de root y devs group, pero root es owner; en retrospectiva, para colaborar quizás mejor cambiar owner a tu usuario o dar g+w a devs). Vamos a ajustar: sudo chown estudiante:devs /proyecto luego sudo chmod 2770 /proyecto (ahora tú eres owner con rwx, devs rwx, otros nada). Tú puedes crear archivos, los devs pueden todo allí. Si pruebas como usuario prueba1 (que añadimos a devs), con sudo -u prueba1 touch /proyecto/archivo2.txt, debería permitírselo (porque pertenece al grupo devs con write). Comprueba ls -l /proyecto: ambos archivos con grupo devs.
Experimentar con chown/chgrp: Crea un archivo en tu home: touch propiedad.txt. Cambia su dueño a root: sudo chown root propiedad.txt. Ahora ls -l mostrará root root. Tú (usuario normal) ya no puedes modificarlo, porque no eres dueño. Intenta echo "X" > propiedad.txt: "Permission denied". Cambia grupo: sudo chown root:devs propiedad.txt o sudo chgrp devs propiedad.txt. Ahora grupo devs tiene el archivo (pero ¿tiene permisos?). Si era 644, devs (grupo) tiene r--, así que ni miembros del grupo pueden escribir. Ajusta chmod g+w propiedad.txt si quieres permitir al grupo escribir.
Umask effect: Ejecuta umask en tu shell. Verás algo como 0002 o 0022. Crea un archivo nuevo touch umask.txt. Mira sus permisos. Con umask 0002 (común en muchas distros para usuarios no root), esperas archivos 664 (rw-rw-r--). Con umask 0022, típicamente 644 (rw-r--r--). Comprueba. Para directorios, la base es 777, restando umask. Así con 0002, dirs se crean 775; con 0022, 755. Prueba: mkdir dir_umask y ve qué permisos tiene.
Analizar un path con namei: Ejecuta namei -l /proyecto/prueba.txt. Esto listará / (permiso x?), proyecto (permiso? owner?), prueba.txt (permisos). Esto es útil si no puedes acceder a un archivo; a veces un directorio intermedio te bloquea. Por ejemplo, namei -l /root te mostrará / (ok) -> root (drwx------, solo root puede entrar). Así entiendes por qué no puedes listar /root como user.

Puntos clave a recordar:

Permisos mínimos: Para leer un archivo necesitas permiso r en él y x en todos los directorios que lo contienen hasta la raíz (para atravesar). Para escribir en un archivo necesitas w en él (y x en dirs). Para borrar un archivo, necesitas w en el directorio que lo contiene (borrar es alterar el contenido del directorio).
Ejecutables y scripts: x en archivos binarios/scripts te permite ejecutarlos. Si es un script interpretado (como bash, Python), también necesitas r muchas veces porque el intérprete leerá el archivo (aunque Linux lo maneja de fondo). Por convención, scripts tienen r+x para owner.
Cambiar el dueño (chown) lo puede hacer root, o el usuario mismo en algunas distros si está habilitado (pero en general usuarios no pueden transferir propiedad arbitrariamente, eso podría permitir esquivar cuotas de disco).
Permisos numéricos vs simbólicos: ambos son útiles. Números para set exacto (especialmente con bits especiales), simbólico para modificaciones relativas (añadir/quitar sin tocar lo demás).
Directorio sin x = no puedes cd a él ni acceder a nada dentro, incluso si sabes el nombre. Directorio sin r pero con x = puedes entrar, pero no listar contenidos (útil para que gente use algo dentro si sabe ruta, pero no vea todo el listado). Directorio sin w = no crear/borrar, incluso si r y x están.
(Imagen sugerida: una tabla o infografía de permisos: mostrar un listado ls -l con colores separando user/group/other, y un pictograma de lo que r,w,x permiten para archivo vs dir. Otra imagen: demostración del efecto de permisos incorrectos, por ejemplo un usuario intentando entrar a un dir sin permiso y recibiendo "Permission denied". Esto refuerza visualmente cómo operan los permisos.)**
Permisos especiales: sticky en /tmp (drwxrwxrwt), setuid en /usr/bin/passwd (-rwsr-xr-x). Puedes mostrar esos ejemplos reales a estudiantes para verlos con ls -l.
Cambiar permisos de muchos archivos: chmod -R con cuidado (recursivo). Por ejemplo, chmod -R u=rwX,go=rX dir – esto da r/w al dueño, r a grupo/otros, y X (mayúscula) significa dar x solo en directorios o si ya tenía x. Útil para aplicar perms estándar recursivo.
Archivos ejecutables sin extensión: en Linux, la capacidad de ejecutar no depende de extensión sino del permiso x y contenido (shebang #! en scripts). Un .sh sin chmod +x no se ejecutará con ./, aunque siempre puedes correrlo con bash script.sh. Si quieres doble click en GUI, necesita +x.

Errores comunes y cómo evitarlos:

777 a todo: Un novato frente a "Permission denied" tentadoramente hace chmod -R 777 a un árbol de directorios para "solucionar" problemas. Esto es muy mala práctica de seguridad. Debes entender qué permisos específica y mínimamente necesita un servicio o usuario, y asignar solo esos. 777 abre escritura a cualquiera, lo que puede ser un riesgo grave. Úsalo solo en casos muy temporales de prueba, y mejor busca alternativas (grupos adecuados, ACLs).
Olvidar la . al usar chmod numérico: Ej, quieres setuid y pones chmod 4755 archivo, pero tecleas chmod 755 archivo por olvido. No verás la s. Siempre verifica con ls -l después de cambios importantes para ver si efectivamente aplicaron.
No incluir a en simbólico: Por ejemplo, chmod +x script.sh en algunas shells modifica para todos (porque interpreta +x como a+x realmente). Pero es mejor ser explícito: chmod u+x si solo tú debes tenerlo. Sin embargo, en muchas distros, tu umask hará que group/other no tengan r de todas formas, así que +x agrega x a user, group, other that already had r... Depende. Sea como sea, deja claro quién: u, g, o, a.
Cambiar dueños recursivamente mal: Cuidado con comandos como chown -R user: / (si cometes ese error, cambiarás dueño de TODO el sistema, rompiendo montones de cosas). Aplica esto: piensa dos veces al usar -R en / o en rutas con comodines expansivos. Mejor especifica un dir concreto o un rango con find.
No darse cuenta de umask en scripts: Si creas archivos desde un script o aplicación, su umask determinará perms. Por ejemplo, un backup puede crear archivos accesibles por más gente de lo deseado si no ajustas umask o chmod post-creación. Siempre considera umask para procesos automatizados (se puede setear con comando umask 077 en script para mayor seguridad de archivos creados, etc.).
Tratar de dar permisos de ejecución a directorios pensando en "abrirlos": En Windows, "abrir carpeta" es distinto. En Linux la ejecución (x) en directorio es necesaria para acceder. A veces confunde: "¿por qué un dir necesita 'execute'?" Piensa x = "traverse".

Tips de rescate si algo falla:

ACLs (Listas de Control de Acceso): Linux soporta ACL extendidas (getfacl, setfacl) que permiten dar permisos más granulares (ej: darle permiso a un usuario específico que no es owner ni pertenece al grupo). Si los permisos estándar no bastan, investiga ACLs. Por ejemplo, setfacl -m u:alice:rwx carpeta daría a alice acceso completo a carpeta sin cambiar owner/grupo globales. Para ver ACLs, getfacl archivo.
Permisos por defecto de directorios (setgid): Ya usamos setgid en /proyecto. Si tienes un proyecto colaborativo, esa es la forma. Además, puedes combinar con ACL para default perms en nuevos ficheros.
Encontrar archivos con permisos específicos: find . -perm 777 listará archivos con permisos 777 (a veces útil para auditar excesos). find / -uid 0 -perm -4000 encuentra archivos suid root, para revisar seguridad. Esto es más avanzado, pero saberlo es bueno.
Evitar cambiar permisos de archivos del sistema inapropiadamente: Confía en los paquetes. A veces alguien piensa "no puedo editar resolv.conf, le doy chmod 666". Mejor aprender que resolv.conf es manejado por NetworkManager, etc. No fuerces permisos en cosas administradas por el sistema, busca el método correcto (por ej, agregar tu usuario a grupo dialout para serial, en vez de chmod 777 al dispositivo /dev/ttyS).
Recuperar permisos default de paquetes: Si accidentalmente cambiaste permisos de archivos de sistema, en distros rpm puedes usar rpm --setperms paquete para restaurar. O consultar rpm -q --scripts paquete por algún script de postinst. En Debian, dpkg-statoverride se usaría. Esperemos no necesites, pero existe remedio para paquetes instalados conocidos.

Criterios de evaluación del módulo:

✅ El alumno interpreta correctamente la notación de permisos en la salida de ls -l, identificando propietario, grupo y permisos para cada.

✅ Sabe modificar permisos de archivos y directorios usando chmod tanto en formato octal como simbólico, aplicándolo en situaciones concretas (por ejemplo, hacer ejecutable un script, proteger un archivo para que solo él lo lea, abrir un directorio colaborativo a un grupo específico, etc.).

✅ Gestiona la propiedad de archivos con chown y chgrp, pudiendo transferir archivos a otros usuarios o reordenar la propiedad según necesidades (con precaución de necesitar privilegios para hacerlo).

✅ Comprende los efectos de los permisos en la interacción práctica: sabe por qué un "Permission denied" puede deberse a falta de x en directorio o de w en archivo, etc., y resuelve estos problemas ajustando los bits adecuados en lugar de aplicar soluciones globales e inseguras.

✅ Conoce la existencia de bits especiales (suid, sgid, sticky) y puede mencionar al menos un ejemplo de su utilidad (aunque no los aplique en profundidad, reconoce su presencia cuando aparecen en listados).

❓ Preguntas de repaso recomendadas:

En la salida drwxr-x---, ¿qué puede hacer el propietario del directorio? ¿y los miembros del grupo? ¿y alguien que no pertenece al grupo?
Si tienes un archivo script.sh con permisos rwxr-xr-x, ¿quiénes pueden ejecutarlo? ¿Quiénes pueden modificarlo?
¿Cómo otorgarías permisos de lectura y escritura a todos los usuarios para un archivo, pero solo de ejecución para el dueño?
Explica con un caso práctico por qué no es buena idea simplemente hacer chmod 777 a un archivo que no puedes abrir, sin entender el trasfondo.
¿Qué significa el bit t al final de los permisos de /tmp? ¿Qué pasaría si no existiera ese bit en /tmp y el directorio fuera 0777 en lugar de 1777?

Requisitos previos al módulo:

Haber realizado los módulos anteriores sobre manejo de archivos y usuarios, ya que los permisos combinan ambos conceptos.
Tener acceso a cuentas múltiples en el sistema (al menos tu usuario normal y la posibilidad de usar root/sudo, y quizá un segundo usuario de prueba) para verificar cómo los permisos impiden o permiten acciones entre usuarios.
Un entorno donde puedas crear directorios y archivos libremente para experimentar con cambios de permisos sin comprometer nada importante. Preferiblemente dentro de tu home o un directorio de pruebas específico.
Comprensión básica de propiedad de archivos: saber qué es un usuario y grupo, y que tu usuario tiene ciertos permisos por ser dueño de sus archivos. Esto ya fue cubierto, pero se reforzará aquí con la práctica.