SSD Nodes Learn Hosting plans →
Guías Matt ConnorPor Matt Connor

drwxr-xr-x explicado: permisos Linux y modo 755

Interpreta drwxr-xr-x carácter por carácter y conviértelo a 755. Entiende la x en directorios y por qué chmod 777 no es la solución correcta.

Qué significa drwxr-xr-x

drwxr-xr-x describe un directorio que su propietario puede modificar y que cualquier otro usuario puede leer y atravesar sin modificarlo. En octal, ese modo es 755. Linux muestra estos diez caracteres al principio de cada línea de la salida de ls -l, y siempre significan lo mismo en el mismo orden. Por eso, aprender una cadena permite interpretar todas las demás.

Hay una regla que debe conocer antes que las demás, porque determina si sus propias pruebas proporcionan información útil. El usuario root ignora los bits de permisos. El kernel concede a root la capacidad CAP_DAC_OVERRIDE (omisión del control de acceso discrecional), por lo que root puede abrir archivos cuyo modo lo impide. Todos los ejemplos de esta página funcionan para root, independientemente de los bits. Inicie sesión como un usuario normal cuando quiera observar cómo se aplican las reglas.

Los diez caracteres, uno por uno

Cree un directorio y un archivo para examinarlos. Nada de lo que sigue afecta a elementos fuera del directorio nuevo.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

Con el valor predeterminado habitual de umask, 022, las dos líneas de directorio empiezan por drwxr-xr-x y la línea del archivo empieza por -rw-r--r--.

El carácter 1 indica el tipo de archivo, no un permiso. d es un directorio. - es un archivo normal. l es un enlace simbólico. c y b son nodos de dispositivo de caracteres y de bloques. s es un socket y p es una tubería con nombre. Este carácter queda fuera del valor octal. Por eso drwxr-xr-x se convierte en 755, en lugar de empezar por un d.

Los nueve caracteres siguientes forman tres grupos de tres y su orden nunca cambia.

  • Los caracteres 2 a 4 forman la tríada del propietario. Sus bits se aplican al usuario propietario del archivo.
  • Los caracteres 5 a 7 forman la tríada del grupo. Sus bits se aplican al grupo del archivo.
  • Los caracteres 8 a 10 forman la tríada de otros. Sus bits se aplican a todos los demás usuarios.

Dentro de una tríada, las posiciones siempre son r, después w y después x. Un guion indica que ese bit está desactivado. Las letras nunca cambian de posición. r-x significa permiso de lectura sin escritura. -w- significa permiso de escritura sin lectura. Es válido, pero poco habitual.

Por tanto, drwxr-xr-x se divide así: d para el directorio, después rwx para el propietario, después r-x para el grupo y después r-x para otros.

Algunos sistemas muestran un undécimo carácter. Un punto final, drwxr-xr-x., indica que el archivo tiene un contexto de SELinux (security enhanced Linux). Las distribuciones que incluyen SELinux, como Fedora y Rocky, lo muestran de forma predeterminada. Un signo más al final, drwxr-xr-x+, indica que el archivo tiene una ACL POSIX (access control list), un conjunto adicional de reglas que se suma a estos nueve bits. Consulte esas reglas adicionales con getfacl <path>.

r, w y x cumplen funciones distintas en un directorio

Esta es la primera regla que los principiantes suelen interpretar mal. Las letras son las mismas en un archivo y en un directorio. Los permisos que conceden no lo son.

  • r en un archivo lee su contenido. r en un directorio lista los nombres que contiene, que es lo que necesita un ls sin opciones.
  • w en un archivo modifica su contenido. w en un directorio agrega y elimina entradas. Eliminar un archivo modifica el directorio, por lo que el permiso de escritura del directorio es el que determina si se puede hacer, y el modo del propio archivo no influye.
  • x en un archivo lo ejecuta como programa. x en un directorio permite atravesarlo, lo que significa que el kernel puede resolver un nombre dentro de él durante la búsqueda de una ruta.

El acceso de recorrido es la parte que más sorprende. x en un directorio no ejecuta nada. Para abrir /srv/site/index.html se necesita x en /, después x en /srv, luego x en /srv/site y, por último, r en el archivo. Si uno de los directorios de esa cadena no tiene x para usted, la búsqueda se detiene allí y el sistema devuelve Permission denied para toda la ruta, aunque el archivo final tenga permisos de lectura para todos. namei -l /srv/site/index.html muestra cada paso de la cadena con sus permisos y propietario, para que pueda ver qué componente la detiene.

Un directorio con r y sin x es un estado intermedio inusual que conviene reconocer. Un usuario normal puede listar los nombres, porque eso es lo que concede r, pero no puede obtener información de estado de ninguna entrada. Por eso ls -l rellena las columnas de tamaño y permisos con signos de interrogación e imprime ls: cannot access ...: Permission denied para cada entrada.

Convertir las letras en 755

Cada terna es un número de tres bits. r vale 4, w vale 2 y x vale 1. Sume los bits activados.

  • rwx es 4 + 2 + 1 = 7
  • rw- es 4 + 2 = 6
  • r-x es 4 + 1 = 5
  • r-- es 4
  • --- es 0

Por tanto, drwxr-xr-x es 7 para el propietario, 5 para el grupo y 5 para otros usuarios: 755. -rw-r--r-- es 6, 4, 4: 644. drwxrwxr-x es 7, 7, 5: 775, que equivale a 755 con permiso de escritura añadido para el grupo. No es necesario contar los caracteres manualmente, porque stat muestra ambas formas a la vez.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A es la forma con letras, %a es la forma octal y %U y %G indican el usuario propietario y el grupo propietario.

Las cadenas de permisos que se buscan con frecuencia

Estos son los modos que encontrará en un servidor real, con el valor octal y el contexto en el que aparece cada uno.

  • -rw-r--r-- es 644. Archivos normales que un servicio sólo lee, como un archivo de configuración o una página HTML.
  • -rw------- es 600. Secretos: una clave privada de SSH o el archivo .env de una aplicación.
  • -rw-rw-r-- es 664. Un archivo de un directorio compartido por un grupo, donde los miembros del equipo necesitan permisos de escritura.
  • -rwxr-xr-x es 755. Scripts y binarios, como /usr/local/bin/backup.sh y la mayoría de /usr/bin.
  • -rwx------ es 700. Un script privado que sólo puede ejecutar su propietario.
  • drwxr-xr-x es 755. Casi todos los directorios del sistema y la raíz de documentos de un sitio web.
  • drwx------ es 700. ~/.ssh y los directorios personales de un sistema restringido.
  • drwxrwxr-x es 775. Un directorio en el que puede escribir el grupo del propietario.
  • drwxrwsr-x es 2775. Lo mismo, además del bit setgid, de modo que los archivos nuevos hereden el grupo del directorio.
  • drwxrwxrwt es 1777. /tmp. El t final es el bit sticky, por lo que un usuario sólo puede eliminar sus propios archivos.
  • -rwsr-xr-x es 4755. Un binario setuid que se ejecuta con la identidad de su propietario, como /usr/bin/passwd y /usr/bin/sudo.
  • -rw-rw-rw- es 666 y drwxrwxrwx es 777. Permisos de escritura para todos, lo que en un servidor casi siempre es un error.
  • lrwxrwxrwx es lo que muestra todo enlace simbólico. Linux ignora los bits de modo de un enlace y comprueba el destino, por lo que esta cadena no tiene ningún significado.

Qué tríada se aplica en su caso

Esta es la segunda regla que los principiantes suelen aplicar mal. El kernel selecciona exactamente una tríada y se detiene.

Si su ID de usuario coincide con el propietario del archivo, obtiene la tríada del propietario. Los bits del grupo y de otros usuarios no se consultan. Si no coincide, pero el grupo del archivo es uno de sus grupos, obtiene la tríada del grupo. En cualquier otro caso, obtiene la tríada de otros usuarios.

De aquí se derivan dos aspectos. La tríada del propietario se aplica incluso cuando es la más restrictiva. Un archivo con modo 0466, que se muestra como -r--rw-rw-, sólo permite leer al propietario y permite escribir a todos los demás, porque la comprobación del propietario coincidió primero y no se leyó nada más. Esto es válido y suele confundir la primera vez.

La tríada del grupo se selecciona según el grupo del archivo, no según la lista de grupos a los que pertenece. ls -l muestra dos nombres en cada línea: primero el propietario y después el grupo. Sólo ese segundo grupo tiene efecto sobre el archivo. Pertenecer a veinte grupos sólo ayuda cuando el archivo tiene uno de ellos.

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id muestra su usuario y todos los grupos a los que pertenece. stat muestra el propietario y el grupo del archivo. Compare ambos resultados para saber qué tríada utilizará el kernel.

Por eso un directorio compartido suele configurarse con un grupo y el bit setgid. sudo chmod 2775 /srv/shared se muestra como drwxrwsr-x. Los archivos creados dentro heredan entonces el grupo del directorio en lugar del grupo personal de quien los crea. Los subdirectorios nuevos también reciben el bit setgid. Setgid establece el grupo, no el modo. Con la umask predeterminada de 022, un archivo nuevo creado dentro sigue teniendo permisos 644. Los demás miembros del equipo pueden leerlo, pero no escribir en él. Para permitir la escritura del grupo, todos los usuarios que trabajen allí necesitan una umask de 002, o el directorio debe tener una ACL predeterminada. Esta sustituye a la umask para los archivos creados dentro. Asignar una cuenta propia a cada servicio es la otra parte de esta configuración. Se explica en un usuario de Linux por servicio en un VPS.

umask determina el modo de cada archivo nuevo

Un archivo nuevo no toma su modo de usted. Lo toma del programa que lo crea, menos los bits que elimina su umask. El umask es una máscara de bits que se deben quitar, por lo que un umask más alto produce archivos más privados.

La mayoría de las distribuciones se publican con 022. Un programa que crea un archivo normal suele solicitar 0666. Un programa que crea un directorio suele solicitar 0777. El umask elimina 022 de ambas solicitudes, por lo que se obtienen 644 en los archivos y 755 en los directorios. Es exactamente la combinación que aparece en un VPS recién instalado.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S muestra el mismo valor con letras, lo que resulta más fácil de leer que 0022. Establezca umask 027 en ~/.profile para usar un valor predeterminado más restrictivo: 640 en los archivos y 750 en los directorios, de modo que su grupo pueda leer su trabajo y nadie más pueda hacerlo. Estos resultados presuponen las solicitudes habituales de 0666 y 0777.

Hay dos límites importantes. El umask sólo puede eliminar bits; nunca puede añadirlos. Un archivo solicitado con 0666, que es lo que solicita touch, nunca será ejecutable, independientemente del valor configurado. Además, un programa que solicita acceso sólo para el propietario lo conserva: mktemp crea archivos con 600 y directorios con 700 con un umask de 022 o 027. Y un servicio de systemd nunca lee el perfil de su shell, por lo que debe establecer el valor en el archivo de unidad.

[Service]
UMask=0027

Hay un caso que omite por completo el umask. Cuando el directorio principal tiene una ACL predeterminada, el umask se ignora y los bits de permisos del archivo nuevo proceden de la ACL heredada.

Por qué los archivos web tienen permisos 644 y los directorios web, 755

Un servidor web se ejecuta con su propia cuenta: www-data en Debian y Ubuntu, y nginx en Rocky y Alma. Ese proceso necesita permisos de lectura en los archivos que sirve y permisos de recorrido en los directorios que los contienen. No tiene ningún motivo para escribir en ellos, y un sitio estático nunca debería permitírselo.

El permiso 644 en un archivo permite escribir al propietario y leer a todos, de modo que el usuario de despliegue puede publicar y el usuario web puede servir los archivos. El permiso 755 en un directorio permite escribir al propietario y recorrerlo a todos, de modo que el usuario web puede seguir la ruta sin poder añadir ni eliminar nada. Si la aplicación tiene un error, no podrá sobrescribir las páginas que está sirviendo.

La regla de recorrido es la que suele causar el problema. Si el sitio está en /home/deploy/site, /home/deploy tiene permisos 750 y el usuario web no pertenece al grupo del directorio, el usuario web no puede entrar en el directorio personal. La petición termina con HTTP 403 y una línea como esta en /var/log/nginx/error.log:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

Ese 13 es EACCES, la denegación de permisos del kernel. No hay ningún problema de red: el puerto está escuchando y la petición llegó. Esto es lo que confunde mientras todavía está aprendiendo cómo funcionan los puertos en escucha en Linux. Ejecute namei -l /home/deploy/site/index.html y siga la cadena hasta encontrar el primer directorio que no tenga x para otros.

Un directorio en el que la aplicación escribe, como una ruta de carga de archivos, es la excepción. Conceda ese acceso mediante la propiedad, no mediante un modo más permisivo: sudo chown -R www-data:www-data /srv/site/uploads y mantenga el modo en 755. Mantenga el acceso de escritura únicamente en el directorio que lo necesita.

chmod, sin aplanar todo el árbol

chmod admite ambas formas. La notación octal establece los nueve bits de una vez: chmod 644 notes.txt. La notación simbólica sólo cambia lo que se indica y deja intacto el resto: chmod u+x deploy.sh añade permiso de ejecución al propietario y chmod go-w notes.txt elimina el permiso de escritura para el grupo y para los demás usuarios.

La recursividad es lo que daña los árboles. chmod -R 755 . marca como ejecutables todas las imágenes y todos los archivos de configuración, porque chmod no puede distinguir un script de un archivo JPEG. Use la opción mayúscula X.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

La opción mayúscula X aplica el permiso de ejecución a los directorios y a los archivos que ya tenían algún bit de ejecución. Los directorios quedan con permisos 755, los archivos normales con permisos 644 y los scripts que ya eran ejecutables conservan ese permiso. Cuando un archivo ya tiene un modo que desea conservar, chmod --reference=good.sh other.sh lo copia al resto.

Los mensajes que aparecen cuando algo está mal

bash: ./deploy.sh: Permission denied significa que el script no tiene el bit x en la tríada que le corresponde, o que algún directorio de su ruta no tiene x. chmod u+x deploy.sh corrige el primer caso.

bash: ./deploy.sh: cannot execute: required file not found es otro error con un nombre confuso. El bit x es correcto, pero falta el intérprete indicado en la primera línea. La causa habitual son los finales de línea de Windows, por lo que el kernel busca un intérprete llamado /bin/bash\r. Corríjalo con sed -i 's/\r$//' deploy.sh.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. procede del cliente SSH, que se niega a usar una clave privada que otros usuarios pueden leer. La clave debe tener permisos 600 y ~/.ssh debe tener permisos 700. La gestión completa de las claves se explica en gestión de claves SSH y sus permisos de archivo.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh aparece en el journal del servidor cuando un directorio personal o su .ssh tiene permisos de escritura para el grupo. La configuración StrictModes de sshd rechaza la clave, y desde el cliente esto se muestra como una solicitud de contraseña inesperada y sin explicación.

sudo: /etc/sudoers is world writable, seguido de sudo: no valid sudoers sources found, quitting, significa que sudo comprobó los permisos de su propio archivo de configuración y se negó a ejecutarse. Ese archivo debe tener permisos 0440 y nunca debe permitir la escritura a todos los usuarios. Esta es la consecuencia habitual de un chmod recursivo aplicado de forma general, y puede aparecer junto con el mensaje de sshd anterior, lo que deja la consola del proveedor como la única forma de recuperar el acceso.

Por qué 777 no es una solución

777 concede acceso de escritura a todas las cuentas de la máquina y a todos los procesos que se ejecutan con cualquiera de esas cuentas. Un servidor ejecuta los servicios con sus propios usuarios, por lo que «todos» abarca mucho más en un VPS que en un portátil. Un servicio comprometido puede escribir en cualquier ubicación donde 777 lo permita.

En la raíz web, el daño es directo. Un directorio con permisos de escritura para todos que además sirve el servidor convierte una vulnerabilidad de carga de archivos en una forma de colocar un script y solicitarlo después.

777 casi siempre es la respuesta incorrecta a un problema de propiedad. El síntoma es «la aplicación no puede escribir en este directorio». La causa es que el directorio pertenece al usuario equivocado. sudo chown -R appuser:appuser /srv/app/storage con el modo 755 lo resuelve: la aplicación puede escribir allí y las demás cuentas todavía pueden listar y acceder al directorio, pero no pueden escribir en él. Crear esas cuentas antes de desplegar nada forma parte de los primeros diez minutos en un VPS nuevo.

La escritura para todos es legítima en un lugar conocido, /tmp, y se escribe drwxrwxrwt. El t final es el sticky bit: todos pueden escribir en el directorio, pero cada usuario sólo puede eliminar los archivos que le pertenecen. Sin ese bit, cualquier cuenta podría eliminar los archivos temporales de otra cuenta.

Lee el modo antes de cambiarlo

Estos comandos sólo leen el estado, por lo que se pueden ejecutar de forma segura en cualquier ubicación.

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 muestra todo lo que hay bajo una ruta cuyo bit de escritura para otros está activado. Es la forma más rápida de auditar un servidor después de que alguien haya estado reparando cosas con chmod 777.

Para comprobar si una cuenta de servicio concreta puede entrar en un directorio, haga la consulta con esa cuenta. sudo -u www-data test -x /srv/site && echo yes || echo no muestra yes cuando ese usuario tiene permiso de recorrido sobre el directorio, y no cuando no lo tiene. Hacer la consulta como root no demuestra nada, porque root omite la comprobación y la respuesta siempre es yes.

FAQ

¿Qué significa drwxr-xr-x en Linux?

Es un directorio, indicado por el d inicial, con el modo 755. La terna del propietario es rwx, por lo que el propietario tiene todos los permisos. La terna del grupo es r-x y la de otros es r-x, por lo que el resto puede listar los nombres que contiene y atravesar el directorio, mientras que sólo el propietario puede añadir o eliminar elementos. Confirme cualquier ruta con stat -c '%A %a %U %G %n' <path>, que muestra la forma con letras y la forma octal una junto a otra.

¿Por qué los archivos web tienen 644 y los directorios web 755?

El servidor web se ejecuta con una cuenta diferente, www-data en Ubuntu. Necesita permiso de lectura en los archivos que sirve y permiso de recorrido en todos los directorios que los contienen, pero no necesita escribir en ninguno de ellos. 644 permite escribir al propietario y leer al resto. 755 permite escribir al propietario y recorrer el directorio al resto. Un directorio en el que la aplicación realmente deba escribir debe asignarse con chown al usuario de esa aplicación, en lugar de ampliar el modo para todos.

¿El bit x significa que puedo ejecutar un directorio?

No. En un directorio, x significa recorrido: es el derecho a resolver un nombre dentro de él mientras el kernel recorre una ruta. cd lo necesita, al igual que cualquier apertura de un archivo situado debajo de él. Cada directorio de la ruta necesita x, por lo que un archivo con modo 644 sigue siendo inaccesible si a un directorio superior le falta x para usted. namei -l /path/to/file muestra el modo de cada directorio de la cadena y permite ver dónde se detiene la búsqueda.

¿Es alguna vez correcto solucionar el problema con chmod 777?

Casi nunca en un servidor. Concede permiso de escritura a todas las cuentas del equipo, incluidas las cuentas con las que se ejecutan los servicios, por lo que un servicio comprometido puede sobrescribir el archivo. Cuando una aplicación no puede escribir en un directorio, el problema real suele ser la propiedad: sudo chown -R appuser:appuser /srv/app/storage con el modo 755 concede acceso de escritura a la aplicación, mientras que las demás cuentas todavía pueden leer el directorio, pero no escribir en él. La excepción habitual es /tmp en 1777, y sólo funciona porque el sticky bit impide que los usuarios eliminen los archivos de otros usuarios.

¿Por qué ls muestra un punto o un signo más después de los permisos?

Ese undécimo carácter describe reglas adicionales a los nueve bits de permisos. Un punto, como en drwxr-xr-x., indica que hay asociado un contexto de seguridad de SELinux, algo normal en Fedora y Rocky. Un signo más, como en drwxr-xr-x+, indica que hay configurada una ACL de POSIX (lista de control de acceso), por lo que algún usuario o grupo tiene permisos que no aparecen en las tres ternas. Ejecute getfacl <path> para mostrar esas entradas adicionales.

¿Te resultó útil este artículo?

#permissions#ls#chmod#linux-basics#octal