Herramientas de desarrollo · Calculadora Chmod
Arreglando nginx 403 Prohibido: los permisos de archivos y directorios que importan
· Por qué es importante
chmod unix control de acceso
Un 403 de nginx suele ser un problema del sistema de archivos, no un problema de configuración. Esta publicación muestra cómo verificar con qué usuario se ejecuta nginx y qué bits necesita en cada directorio de la ruta.
403 en un sitio estático que funcionó localmente: los archivos provienen de /home/deploy y nginx dice prohibido para cada URL
Un nginx 403 puede involucrar bits de modo, pero esta ruta no puede identificar su causa. La calculadora no tiene integración de nginx, registros, analizador de configuración, búsqueda de procesos ni recorrido de ruta. Responde a preguntas más específicas: si una clase de directorio se ha ejecutado y si una clase de archivo normal ha leído, lo que ayuda a interpretar la evidencia recopilada en otros lugares.
Comience con los modos exactos observados en cada componente de la ruta en lugar de asumir los valores predeterminados. Ingrese a cada modo y elija su tipo de objetivo. El texto simbólico, las casillas de verificación y la prosa exponen los permisos de clase y confirman la conversión, pero no pueden mostrar que nginx intentó acceder, qué identidad utilizó o si los permisos del sistema de archivos produjeron la respuesta.
Un 403 puede involucrar bits de modo, pero esta ruta no puede identificar su causa
La calculadora no puede descubrir una identidad de trabajador nginx. Modela propietarios, grupos y otras clases, pero no nombres de usuarios, procesos ni membresías. Por lo tanto, un modo como rwxr-xr-x no dice nada sobre si un trabajador es propietario del objeto, pertenece a su grupo o pertenece a otro. La inspección externa deberá establecer dicha clasificación.
El descubrimiento de identidad debe preceder a las afirmaciones sobre bits relevantes. Una vez que la evidencia establece la clase aplicable, la matriz muestra que se lee como 4, se escribe como 2 y se ejecuta como 1. Antes de eso, el grupo de edición u otro es una conjetura. La ruta no lee ningún estado de proceso; traduce los modos suministrados en lugar de inferir la arquitectura del servidor.
La calculadora no descubre una identidad de trabajador nginx
Inspeccione cada componente del directorio como un modo suministrado por separado. Para directorios, ejecutar permite entradas y acceso basado en nombres, leer permite enumerar y escribir permite crear, cambiar nombres y eliminar entradas. La explicación específica del objetivo ayuda a los revisores a determinar si la clase establecida externamente se ha ejecutado en un componente en particular sin pretender inspeccionar la ruta en sí.
El navegador no va de la raíz a la raíz web. No puede localizar un componente de bloqueo, confirmar su existencia ni inspeccionar las ACL. Proporcione cada modo de directorio observado por separado, luego verifique el objeto final como un archivo normal, donde la lectura se refiere a contenidos en lugar de listados. Esto interpreta la evidencia recopilada en lugar de reemplazar la inspección del sistema de archivos.
Los archivos necesitan r, y nada más: por qué 644 es suficiente para archivos estáticos y por qué 755 en archivos no es la solución
Para un archivo estático, 644 representa rw-r--r--. El propietario recibe lectura y escritura, mientras que el grupo y otros reciben lectura; nadie recibe ejecutar. Esta conversión muestra que la lectura y ejecución de archivos son bits separados. La página no tiene base para decidir si es necesario ejecutar un servidor en particular, porque la política del servidor está ausente.
Mantenga distintas las explicaciones de archivos y directorios. La ejecución de directorio significa accesibilidad basada en entradas y nombres, mientras que la ejecución de archivos normal significa ejecutar un programa. Por lo tanto, la misma casilla de verificación tiene una prosa específica para el objetivo. Comparar 644 con 755 aclara bits, pero no puede diagnosticar un 403 ni prescribir un modo universal sin configuración, identidad, ACL y contexto de política.
Ejemplo resuelto: seguimiento de /home/deploy/site/index.html — namei -l en la ruta y la línea ls -l que revela el bloqueador
Un ejemplo compatible comienza después de que se recopilan pruebas de ruta en otro lugar. Supongamos que los componentes del directorio son 755 y el archivo final es 644. La calculadora representa los directorios como rwxr-xr-x, explicando el grupo y otras ejecuciones como entrada y accesibilidad. Representa el archivo como rw-r--r--, explicando el grupo y otras lecturas como acceso al contenido.
Si un componente es 750, su otro triplete es ---, mientras que el grupo permanece r-x. Esa diferencia puede importar, pero no prueba que nginx use otra. La ruta no puede ejecutar namei o ls, por lo que la evidencia externa debe proporcionar rutas y modos. Luego sincroniza cada representación para reducir los errores de transcripción durante la revisión.
Ejemplo resuelto: inspeccionar los modos proporcionados para cada componente de una ruta
Las decisiones de propiedad permanecen fuera del modo de conversión. El panel no lee ningún propietario o grupo y no ofrece ninguna operación chown o chgrp. No puede elegir entre implementación, servicio o propiedad de grupo compartido, ni evaluar contenido en movimiento. Esas decisiones requieren pruebas del sistema y de la carga de trabajo que no se encuentran en las fuentes; ningún modo generado puede reemplazar ese contexto.
Una vez que la propiedad se resuelve en otro lugar, compare cómo los modos dividen el acceso. El modo 750 otorga permisos completos de propietario, lectura y ejecución de grupo, y nada a otros; 755 agrega otras lecturas y ejecuciones. Esto sigue estando condicionado a conocer la clase del trabajador. La vista previa del comando inerte no cambia de propietario ni confirma el acceso al servidor.
Las opciones de propiedad siguen siendo externas a la conversión de modo
La configuración, la selección de índice, el control de acceso obligatorio y el comportamiento ascendente no se diagnostican aquí. Ninguna fuente carga la configuración de nginx, verifica un URI o índice, lee registros, contacta a un upstream u observa SELinux o AppArmor. Por lo tanto, convertir correctamente un modo proporcionado no puede establecer por qué nginx devolvió 403; La evidencia del servidor debe responder a esa pregunta.
Conserve esta distinción cuando un modo parezca sospechoso. El panel puede mostrar que a una clase de directorio le falta ejecución o a una clase de archivo le falta lectura, pero la relevancia depende de la identidad y la evidencia de ruta. Los bits permisivos tampoco pueden excluir otras causas. Indique exactamente lo que permite el modo y luego regrese a los diagnósticos específicos del servidor.
Configuración, índice, MAC y causas ascendentes no se diagnostican
El acceso a la ruta puede depender de cada componente, pero la calculadora ve un valor proporcionado a la vez. Su punto fuerte es la decodificación precisa: el texto octal, simbólico y las casillas de verificación permanecen sincronizados, mientras que la prosa de directorio distingue listado, modificación y entrada. Simplifica la revisión sin pretender descubrir ni los componentes ni el proceso que intenta acceder.
Establezca la identidad del servidor y recopile modos de ruta fuera de esta ruta. Decodifica cada directorio como un directorio y el objeto final como un archivo normal, centrándote en la clase verificada externamente. Investigue la configuración, las ACL y la política obligatoria por separado. La calculadora valida la aritmética, pero no puede identificar la causa de 403 ni verificar una solución.