Módulo 4: Permisos, procesos y entorno

3. Leer y cambiar permisos: rwx, octal y chmod

Descripción

Escribes un script, le das doble clic mental con ./deploy.sh y la terminal te devuelve Permission denied sin explicarte nada más. El archivo existe. Lo puedes abrir en tu editor, leer cada línea, hasta copiarlo. Pero no corre. O al revés: clonas un repositorio, generas una llave SSH para conectarte a un servidor, y ssh se niega en seco con un mensaje sobre "permissions are too open" que no se parece en nada a los Permission denied que ya conoces.

Al final de esta lección vas a poder leer una cadena como -rwxr-xr-x letra por letra y decir con precisión qué puede hacer cada tipo de usuario con ese archivo. Vas a poder cambiar esos permisos con chmod, tanto en notación simbólica (u+x, go-w) como en octal (755, 644, 600), sin adivinar ni copiar un número de un foro sin entenderlo. Y vas a entender por qué chmod 777 — que aparece en una fracción enorme de las respuestas de Stack Overflow — casi nunca es la respuesta correcta, y qué hace realmente cuando lo ejecutas.

Esto no es un ejercicio académico. Un pipeline de integración continua falla porque un script de despliegue perdió su bit de ejecución al copiarse entre sistemas. Una llave SSH rechazada bloquea un despliegue de producción a las once de la noche. Un archivo .env con credenciales de base de datos queda legible para cualquier otra cuenta en un servidor compartido porque nadie ajustó sus permisos al crearlo. Los tres casos se resuelven en treinta segundos si sabes leer y escribir permisos; se resuelven por superstición (chmod -R 777 y a rezar) si no sabes.

Conexión con el módulo: en la lección anterior conociste el modelo de tres clases — propietario, grupo y otros — y entendiste por qué Permission denied es una característica del sistema, no una falla tuya. Te quedaste, a propósito, en el nivel conceptual: sabías que existen tres clases, pero todavía no traducías letra por letra lo que ls -l te mostraba sobre ellas, ni tenías el comando para cambiar esos bits. Eso es exactamente lo que resuelve esta lección: te da el vocabulario completo para leer cualquier permiso que veas en tu terminal y la herramienta para cambiarlo con intención. La siguiente lección da un paso más: pregunta quién es realmente el propietario y el grupo de un archivo, y qué hacer cuando necesitas privilegios que hoy no tienes.

Diez caracteres que ya conocías a medias

Piensa en la fila de diez caracteres que ls -l pone al principio de cada línea como una credencial de acceso repetida tres veces seguidas, una por cada público distinto: primero la credencial que tienes tú como propietario, después la que le diste a tu grupo de trabajo, y al final la credencial genérica que le queda a cualquier otra persona con cuenta en esa máquina. Las tres credenciales responden exactamente las mismas tres preguntas, en el mismo orden: ¿puede leer?, ¿puede escribir?, ¿puede ejecutar o entrar? Diez caracteres, tres bloques idénticos en estructura, uno detrás de otro.

Eso es literalmente lo que ya viste en la columna de permisos de ls -l en la lección anterior, sin haberla descompuesto todavía carácter por carácter. Vamos a hacerlo ahora sobre un ejemplo real: drwxr-xr-x.

d rwx r-x r-x
│ │   │   │
│ │   │   └── otros        (o) → r-x : puede leer y atravesar/ejecutar, no escribir
│ │   └────── grupo        (g) → r-x : puede leer y atravesar/ejecutar, no escribir
│ └────────── propietario  (u) → rwx : puede leer, escribir y atravesar/ejecutar
└──────────── tipo de entrada: d = directorio ( - = archivo regular · l = enlace simbólico )

El primer carácter nunca es un permiso: es el tipo de la entrada. - para un archivo regular, d para un directorio, l para un enlace simbólico (hay algunos tipos más raros, pero estos tres cubren casi todo lo que vas a ver). Los nueve caracteres que siguen se agrupan en bloques de tres, y cada bloque es siempre el mismo trío de preguntas en el mismo orden: r (¿lee?), w (¿escribe?), x (¿ejecuta o atraviesa?). Un guion (-) en cualquier posición significa "esta pregunta se responde no" para esa clase.

Sobre un archivo regular, las tres respuestas significan exactamente lo que imaginas:

Permiso	Sobre un archivo regular
`r`	Puedes leer su contenido: `cat`, abrirlo en un editor, copiarlo
`w`	Puedes modificar su contenido o borrarlo (sobrescribirlo, truncarlo, borrar líneas)
`x`	Puedes ejecutarlo como programa — si además el sistema sabe cómo correrlo (un binario compilado, o un script con su línea `#!/bin/bash` al inicio)

Ejemplo trabajado

Corre esto en tu terminal — vas a ver tres líneas con estructura distinta:

ls -l

Qué esperar (los nombres, el tamaño y la fecha van a variar en tu máquina; lo que importa es la columna de permisos):

-rw-r--r--  1 alex  staff   350 Jul 20 09:14 report.csv
-rwxr--r--  1 alex  staff   220 Jul 20 09:14 deploy.sh
drwxr-xr-x  3 alex  staff    96 Jul 20 09:14 scripts

Descompón cada una con la tabla de arriba, sin ejecutar todavía ningún chmod:

report.csv → propietario rw- (lee y escribe, no ejecuta), grupo r-- (solo lee), otros r-- (solo lee). Es justo lo que esperarías de un archivo de datos: nadie necesita "ejecutar" un CSV.
deploy.sh → propietario rwx (lee, escribe y ejecuta), grupo r--, otros r--. Alguien ya le dio permiso de ejecución al propietario para este script.
scripts → es un directorio (d inicial), propietario rwx, grupo r-x, otros r-x. Fíjate que ni grupo ni otros tienen w: nadie fuera del propietario puede crear o borrar archivos dentro de esta carpeta, aunque sí puedan entrar y ver qué hay.

Vas a usar exactamente esta misma lectura, línea por línea, cada vez que necesites decidir si un Permission denied viene de un permiso de lectura, de escritura o de ejecución faltante — antes de tocar nada con chmod.

Lo que cambia cuando el tercer bit vive en un directorio

Hasta acá, x fue fácil de aceptar: en un archivo, ejecutar significa exactamente lo que imaginas, correr el programa. Pero la misma letra, en la misma posición, sobre un directorio, no significa "ejecutar la carpeta" — las carpetas no son programas, no hay nada que correr. Significa otra cosa, y es la confusión que más tiempo le cuesta a quien empieza con la terminal.

Imagina un pasillo de archivo con un torniquete en la entrada y, más adentro, una fila de cajones con etiquetas. Si tienes la llave del torniquete pero no una linterna para leer las etiquetas desde la entrada, puedes caminar hasta el fondo del pasillo y abrir un cajón específico — pero solo si alguien ya te dijo exactamente cuál es, porque no puedes "ver" la fila completa para elegir uno al azar. Si en cambio tienes la linterna pero no la llave del torniquete, puedes pararte en la entrada y leer todas las etiquetas de la fila — sabes exactamente qué cajones existen y cómo se llaman — pero no puedes caminar hasta ninguno de ellos para abrirlo.

Eso, sin metáfora, es la diferencia entre r y x en un directorio:

Permiso	Sobre un directorio
`r`	Puedes listar los nombres que contiene (`ls` sin más)
`x`	Puedes atravesarlo — entrar con `cd`, o llegar a un archivo específico de adentro si ya conoces su nombre exacto (así sea con `cat`, `cd`, o cualquier ruta que lo mencione)
`w` (junto con `x`)	Puedes crear o borrar entradas dentro (archivos o subdirectorios), no editar el contenido de lo que ya está adentro

Son dos preguntas independientes. Puedes tener una sin la otra, y el resultado es distinto en cada caso. Vamos a comprobarlo, no solo a leerlo.

Ejemplo trabajado

Crea un directorio de práctica con un archivo adentro (no necesitas privilegios especiales, es tuyo):

mkdir -p ~/lab-permissions/secrets
echo "abc123" > ~/lab-permissions/secrets/token.txt

Quítale todos los permisos al directorio (000 = nada, para ninguna clase):

chmod 000 ~/lab-permissions/secrets
ls ~/lab-permissions/secrets

Qué esperar:

ls: secrets: Permission denied

Sin sorpresas: sin r ni x, no puedes ni listar ni entrar. Ahora dale solo x al propietario (chmod 100, el 1 es exactamente el bit de ejecución/atravesar, según la tabla octal que ves más abajo):

chmod 100 ~/lab-permissions/secrets
ls ~/lab-permissions/secrets

Qué esperar (el mensaje exacto varía un poco entre macOS y Linux, pero el resultado es el mismo: falla):

ls: secrets: Permission denied

ls sigue fallando — necesita r para leer la lista de nombres, y no se lo diste. Pero mira qué pasa si accedes a un archivo cuyo nombre ya conoces, en vez de pedirle a la carpeta que te muestre qué contiene:

cat ~/lab-permissions/secrets/token.txt

Qué esperar:

abc123

Funcionó. x te dejó atravesar el directorio hasta llegar a token.txt, aunque ls sobre ese mismo directorio siga fallando. Ahora invierte la situación — quítale x al propietario y dale solo r (chmod 400):

chmod 400 ~/lab-permissions/secrets
ls ~/lab-permissions/secrets

Qué esperar:

token.txt

Ahora ls sí funciona: puedes ver el nombre. Pero intenta leer ese mismo archivo que acabas de ver listado:

cat ~/lab-permissions/secrets/token.txt

Qué esperar:

cat: /Users/alex/lab-permissions/secrets/token.txt: Permission denied

Ahí está la prueba completa: puedes ver el nombre token.txt porque tienes r, pero no puedes llegar hasta él porque te falta x — aunque el archivo en sí tenga permiso de lectura de sobra. Ver el nombre de algo y poder alcanzarlo son dos permisos distintos, y esta es la razón exacta por la que un directorio típico de trabajo lleva rwxr-xr-x (755): todos pueden listar y atravesar, solo el propietario puede modificar qué hay adentro.

Deja todo en un estado usable y limpia tu laboratorio:

chmod 755 ~/lab-permissions/secrets
rm -rf ~/lab-permissions

chmod: cambiar esos bits, sin adivinar

chmod ("change mode") tiene dos gramáticas distintas para decir lo mismo, y vale la pena dominar ambas porque vas a encontrarte las dos constantemente: una lee como una frase (simbólica) y la otra se escribe como un número (octal).

Notación simbólica. Combinas una clase, un operador y un permiso:

Clase	Significa
`u`	propietario (user)
`g`	grupo
`o`	otros (others)
`a`	todos (all = u+g+o)

Operador	Significa
`+`	agrega el permiso indicado, deja el resto tal como está
`-`	quita el permiso indicado, deja el resto tal como está
`=`	fija el permiso exactamente así, borrando lo que no menciones

Así, chmod u+x deploy.sh agrega ejecución al propietario sin tocar nada más. chmod go-w file.txt le quita escritura al grupo y a otros. chmod u=rw,g=r,o= file.txt fija exactamente lectura-escritura para el propietario, solo lectura para el grupo, y nada para otros — sin importar qué tenía antes.

Notación octal. Cada clase se resume en un solo dígito, sumando el valor de cada permiso que quieras activar:

Valor	Permiso
`4`	leer (`r`)
`2`	escribir (`w`)
`1`	ejecutar/atravesar (`x`)
`0`	nada

Sumas los valores que quieres para cada clase — por ejemplo rwx es 4+2+1=7, r-x es 4+0+1=5, rw- es 4+2+0=6 — y escribes los tres dígitos seguidos, uno por clase, en el mismo orden de siempre (propietario, grupo, otros):

Octal	rwx	Combinaciones típicas donde aparece
`755`	`rwxr-xr-x`	scripts y directorios de uso normal
`644`	`rw-r--r--`	archivos de datos normales (texto, CSV, configuración pública)
`700`	`rwx------`	directorios privados, solo el propietario entra
`600`	`rw-------`	archivos con secretos: llaves privadas, `.env`

Ejemplo trabajado

Vuelve a tu script del principio de la lección. Créalo así, con permisos de solo lectura de entrada:

printf '#!/bin/bash\necho "Desplegando..."\n' > deploy.sh
chmod 644 deploy.sh
./deploy.sh

Qué esperar:

-bash: ./deploy.sh: Permission denied

El archivo existe, lo puedes leer y modificar (644 = rw-r--r--), pero ningún dígito ahí tiene el 1 de ejecución. Arréglalo en notación simbólica, dándole ejecución solo al propietario:

chmod u+x deploy.sh
./deploy.sh

Qué esperar:

Desplegando...

El mismo resultado, expresado en octal, sería chmod 744 deploy.sh (propietario rwx = 7, grupo r-- = 4, otros r-- = 4) — es exactamente la misma operación descrita con la otra gramática. Si en cambio quieres que cualquiera en tu equipo pueda ejecutarlo pero no editarlo, la combinación correcta es chmod 755 deploy.sh (propietario rwx, grupo y otros r-x): pueden leer y correr el script, nadie fuera de ti puede cambiarle una línea.

Limpia el archivo de prueba cuando termines: rm deploy.sh.

Cuándo el atajo sale caro: -R, llaves SSH, .env y el mito del 777

-R cambia todo lo que encuentra, sin distinguir. chmod -R 755 project/ aplica el mismo número a cada archivo y cada directorio dentro de project/, recursivamente. El problema es que un directorio típico necesita x para que se pueda atravesar, pero un archivo de datos normal (un .csv, un .json, un .md) casi nunca debería tener x — no es un programa. Un chmod -R 755 deja archivos de datos marcados como ejecutables sin ninguna razón, y un chmod -R 777 sobre un proyecto completo lo vuelve escribible por cualquier cuenta del sistema, archivo por archivo. La documentación oficial de GNU Coreutils señala además un riesgo más concreto: combinar -R con las opciones que siguen enlaces simbólicos puede dejar que alguien introduzca un symlink hacia un destino arbitrario durante el recorrido, y termines cambiándole permisos a algo que nunca quisiste tocar. La alternativa correcta es tratar directorios y archivos por separado:

find project -type d -exec chmod 755 {} \;
find project -type f -exec chmod 644 {} \;

Esto le da a cada directorio el x que necesita para ser atravesado y a cada archivo el permiso de datos que le corresponde, sin regalarle ejecución a nada que no la necesite. Si además tienes scripts reales que sí deben ejecutarse, les agregas x puntualmente después, con chmod +x sobre esos archivos específicos.

Llaves SSH y archivos .env: el sistema exige, la convención recomienda. Con las llaves SSH, esto no es una sugerencia: el propio cliente y servidor SSH rechazan la conexión si los permisos son más abiertos de lo esperado, precisamente porque una llave privada legible por cualquiera deja de ser privada.

Ruta	Permiso exigido	Por qué
`~/.ssh/`	`700`	Solo tú puedes entrar a tu propio directorio de configuración SSH
`~/.ssh/id_ed25519` (llave privada)	`600`	Solo tú puedes leerla; si otra cuenta pudiera leerla, podría hacerse pasar por ti
`~/.ssh/id_ed25519.pub` (llave pública)	`644`	Es pública por diseño: compartirla es el punto
`~/.ssh/authorized_keys`	`600`	Define quién puede entrar como tú; nadie más debería poder editarlo

Un archivo .env con credenciales de base de datos o llaves de API no tiene ningún programa del sistema operativo vigilando sus permisos — nada te va a rechazar la conexión por tenerlo mal configurado. Pero la lógica es idéntica a la de una llave privada: si otra cuenta en el mismo servidor puede leerlo (644 o peor), tus secretos ya no son secretos. La convención sensata, aplicando el mismo criterio de menor privilegio de la lección anterior, es chmod 600 .env: solo tú lees, solo tú escribes, nadie más ni siquiera puede intentarlo.

Por qué chmod 777 aparece en todas partes — y por qué casi nunca es la respuesta. 777 significa rwxrwxrwx: lectura, escritura y ejecución para el propietario, el grupo y otros — es decir, para absolutamente cualquier cuenta del sistema. Aparece tanto en foros porque, superficialmente, "arregla" cualquier Permission denied: si el problema era falta de lectura, falta de escritura o falta de ejecución, 777 cubre las tres al mismo tiempo, para todo el mundo, sin que quien lo escribe tenga que pensar cuál de las tres faltaba. Es la respuesta de quien no quiere diagnosticar. El costo es que anula por completo el modelo de tres clases que aprendiste en la lección anterior: ya no importa si alguien debería o no tener acceso, porque todos lo tienen. En un servidor compartido, cualquier otra cuenta puede leer, modificar o borrar ese archivo. En un contenedor o una máquina con más de un servicio corriendo, un proceso comprometido en un servicio distinto puede modificar tus archivos con 777, incluidos scripts que tú mismo vas a ejecutar después. Casi siempre el Permission denied real se arregla con un permiso mucho más angosto — chmod +x cuando falta ejecución, o un problema de propiedad (quién es realmente el dueño del archivo), que es exactamente el tema de la próxima lección.

Errores comunes

"Le di x a esta carpeta, ya debería funcionar" (y sigue el Permission denied). Lo que pasa: cambiaste los permisos del directorio final en la ruta, pero uno de los directorios padre en el camino —quizás varios niveles arriba— no tiene x para la cuenta que intenta acceder. Por qué ocurre: como viste en el ejemplo trabajado, el sistema necesita x en cada directorio que forma parte de la ruta para poder resolverla completa, no solo en el directorio donde vive el archivo. Cómo detectarlo: revisa con ls -ld cada directorio de la ruta, uno por uno, desde la raíz hasta el archivo (en Linux, namei -l /ruta/completa hace exactamente esto de un solo golpe, mostrando los permisos de cada segmento; en macOS no viene instalado por defecto, así que la revisión manual con ls -ld funciona en cualquier sistema). Cómo corregirlo: agrega x al directorio específico que rompe la cadena, no a todos — normalmente basta con uno.

"Corrí chmod -R 777 . para que compilara/desplegara, y ahora git status me muestra cientos de archivos modificados que no toqué." Lo que pasa: Git guarda el bit de ejecución de cada archivo como parte de su historial (lo ves como old mode 100644 / new mode 100755 en git diff). Un chmod -R sobre todo el repositorio cambia ese bit en archivos que antes no lo tenían, y Git lo interpreta como un cambio real, aunque ni una sola línea de contenido haya cambiado. Cómo detectarlo: git status muestra una cantidad sospechosamente alta de archivos "modificados" justo después de un chmod -R, y git diff --summary confirma que son puros cambios de modo, sin líneas agregadas ni quitadas. Cómo corregirlo: no repitas -R con un solo número; usa la misma técnica de find separada por tipo que viste arriba (directorios a 755, archivos a 644, y +x solo en los scripts reales) para devolver cada archivo a su permiso correcto antes de hacer commit.

"Copié chmod 4777 de un foro pensando que era una versión 'más permisiva' de 777." Lo que pasa: un octal de cuatro dígitos no es "777 con un extra de refuerzo" — el primer dígito no representa rwx en absoluto. Es un bit especial aparte: 4 activa setuid (el archivo se ejecuta con los privilegios de su propietario, sin importar quién lo corra), 2 activa setgid, y 1 activa el sticky bit. chmod 4777 deja un archivo -rwsrwxrwx — con una s donde esperabas la x del propietario — es decir, un binario que cualquiera puede ejecutar con los privilegios de quien sea su dueño. Cómo detectarlo: en ls -l, una s (o una S mayúscula) en la posición de ejecución del propietario, en vez de x o -, es la señal inequívoca de setuid activo. Cómo corregirlo: si no sabes con certeza que necesitas setuid (algo raro fuera de un puñado de utilidades del sistema como sudo mismo), usa chmod 0755 para limpiar ese primer dígito y volver a permisos normales.

Ejercicios

1. Decodifica y convierte

Tienes esta línea de ls -l:

-rwxr-x---  1 alex  staff   512 Jul 20 09:14 run.sh

Describe en una frase qué puede hacer cada clase (propietario, grupo, otros) con este archivo, y convierte el permiso a su equivalente en octal.

Ver solución

Propietario: rwx → puede leer, modificar y ejecutar run.sh. Grupo: r-x → puede leer y ejecutar, pero no modificar. Otros: --- → no puede hacer absolutamente nada con este archivo, ni siquiera leerlo.

En octal: propietario rwx = 4+2+1 = 7; grupo r-x = 4+0+1 = 5; otros --- = 0. El permiso completo es 750.

Por qué funciona: cada bloque de tres caracteres se traduce de forma independiente sumando los valores 4 (r), 2 (w) y 1 (x) que estén presentes; el resultado final es la concatenación de los tres dígitos en el orden propietario-grupo-otros.

2. Compártelo con tu equipo, no con el mundo

Escribiste run.sh y quieres que cualquiera en tu grupo de trabajo pueda leerlo y ejecutarlo, pero nadie fuera de ese grupo debería ni siquiera poder abrirlo. Escribe el comando chmod que lo logra, en notación octal y en notación simbólica.

Ver solución

Octal: chmod 750 run.sh (propietario rwx, grupo r-x, otros ---).

Simbólico: chmod u=rwx,g=rx,o= run.sh — fija exactamente esos tres valores, sin depender de qué tenía el archivo antes.

Por qué funciona: "leer y ejecutar, no escribir" para el grupo es r-x (4+1=5); "nada" para otros es 0 o, en simbólico, o= sin ningún permiso después del igual, que borra cualquier permiso previo de esa clase.

3. Predice antes de ejecutar

Un directorio tiene permisos d--x--x--x (octal 111: solo ejecución, para las tres clases, sin lectura en ninguna). Si conoces el nombre exacto de un archivo legible que hay adentro, ¿puedes leerlo con cat? ¿Puedes hacer ls de ese directorio y ver qué contiene? Justifica cada respuesta antes de probarlo.

Ver solución

cat sobre el archivo con nombre conocido sí funciona: x en el directorio te permite atravesarlo para llegar a ese nombre específico, y de ahí en adelante lo que decide si puedes leer el archivo son los permisos del archivo mismo, no los del directorio.

ls sobre el directorio falla: listar los nombres que contiene requiere r en el propio directorio, y aquí ninguna clase lo tiene. Puedes entrar a lo que ya conoces, pero no puedes descubrir qué más hay ahí.

Por qué funciona: este es exactamente el patrón que viste en el ejemplo trabajado con secrets/ — 111 es la combinación real que usan algunos sistemas para directorios donde se permite acceder a archivos por ruta exacta (por ejemplo, un servidor web sirviendo archivos por URL) sin exponer un listado completo a quien no debería verlo.

4. El desastre del -R en el repositorio

Un compañero corrió chmod -R 777 . dentro de un repositorio Git para "arreglar" un error de permisos antes de hacer commit. ¿Qué le recomiendas revisar antes de hacer push, y cómo lo arregla sin volver a usar un único número con -R?

Ver solución

Que revise git status y git diff --summary: probablemente va a ver decenas o cientos de archivos marcados como modificados, con cambios de modo (old mode 100644 → new mode 100755) y ningún cambio real de contenido — la firma clásica de un chmod -R que pasó por encima de todo el árbol.

Para corregirlo sin repetir el mismo error: separar directorios de archivos con find, dándole 755 a los directorios (necesitan x para atravesarse) y 644 a los archivos de datos (no necesitan ejecución), y agregar +x puntualmente solo a los scripts que de verdad deban ejecutarse. Recién entonces git status debería volver a mostrar únicamente los cambios de contenido intencionales.

Por qué funciona: Git versiona el bit de ejecución como parte del modo del archivo; la única forma de que git status quede limpio es que cada archivo termine con el permiso que realmente le corresponde, no un número parejo aplicado a todo el árbol.

Resumen y siguiente paso

Antes de avanzar deberías poder:

leer cualquier cadena de diez caracteres tipo -rwxr-xr-x y decir, sin dudar, qué puede hacer cada clase (propietario, grupo, otros);
explicar la diferencia entre x en un archivo (ejecutar) y x en un directorio (atravesar), y por qué necesitas x en cada directorio de una ruta, no solo en el último;
traducir entre notación simbólica (u+x, g=rx, o-w) y octal (755, 644, 600) en ambas direcciones;
aplicar los permisos que corresponden a llaves SSH (700/600) y a archivos con secretos (600), y explicar por qué chmod 777 casi nunca es la respuesta correcta a un Permission denied.

Hoy resolviste el qué — qué significan los bits y cómo cambiarlos — pero en todo el camino diste por hecho que el archivo ya era tuyo, que podías aplicarle chmod sin pedirle permiso a nadie más. Eso no siempre es así. La próxima lección resuelve el quién: qué es exactamente ser "propietario" o pertenecer a un "grupo" a nivel del sistema, cómo cambiar esa identidad con chown y chgrp, y qué hacer — con la herramienta correcta, no con reflejo — cuando necesitas privilegios que hoy no tienes.

Recursos

chmod(1) — Linux manual page — referencia completa de la sintaxis simbólica y octal, y de todas las opciones de línea de comandos.
path_resolution(7) — Linux manual page — la fuente autorizada de por qué x en un directorio es "permiso de búsqueda" (search permission) necesario para resolver cada componente de una ruta.
chmod invocation — GNU Coreutils Manual — documentación oficial de -R y el riesgo de seguridad de combinarlo con el seguimiento de enlaces simbólicos.
Validating Configuration Permissions — Oracle Linux OpenSSH docs — por qué OpenSSH exige permisos estrictos en ~/.ssh y en las llaves privadas, y qué pasa si no los cumples.
setuid, setgid, and the Sticky Bit Explained — Linuxize — qué hace realmente el dígito extra en un octal de cuatro cifras como 4777.

← Anterior2. Usuarios, grupos y por qué existen los permisos Siguiente →4. Propiedad, sudo y root: el poder peligroso