Outils de développement · Calculatrice Chmod
Correction de nginx 403 Interdit : les autorisations de fichiers et de répertoires qui comptent
· Pourquoi c'est important
chmod unix contrôle d'accès
Un 403 de nginx est souvent un problème de système de fichiers, pas un problème de configuration. Cet article montre comment vérifier sous quel utilisateur nginx s'exécute et de quels bits il a besoin sur chaque répertoire du chemin.
403 sur un site statique qui fonctionnait localement — les fichiers provenaient de /home/deploy et nginx dit interdit pour chaque URL
Un nginx 403 peut impliquer des bits de mode, mais cette route ne peut pas identifier sa cause. La calculatrice n'a pas d'intégration nginx, de journaux, d'analyseur de configuration, de recherche de processus ou de chemin d'accès. Il répond à des questions plus précises : si une classe de répertoire a été exécutée et si une classe de fichier standard a lu, aidant ainsi à interpréter les preuves collectées ailleurs.
Commencez par les modes exacts observés sur chaque composant de chemin plutôt que de supposer des valeurs par défaut. Entrez dans chaque mode et choisissez son type de cible. Le texte symbolique, les cases à cocher et la prose exposent les autorisations de classe et confirment la conversion, mais ne peuvent pas montrer que nginx a tenté d'accéder, quelle identité il a utilisée ou si les autorisations du système de fichiers ont produit la réponse.
Un 403 peut impliquer des bits de mode, mais cette route ne peut pas identifier sa cause
La calculatrice ne peut pas découvrir l'identité d'un travailleur nginx. Il modélise le propriétaire, le groupe et d'autres classes, mais pas les noms d'utilisateur, les processus ou les adhésions. Un mode tel que rwxr-xr-x ne dit donc rien sur le fait qu'un travailleur possède l'objet, appartient à son groupe ou relève d'un autre. Une inspection externe doit établir cette classification.
La découverte d'identité doit précéder les réclamations sur les bits pertinents. Une fois que les preuves établissent la classe applicable, la matrice indique lire comme 4, écrire comme 2 et exécuter comme 1. Avant cela, l'édition d'un groupe ou autre n'est qu'une conjecture. La route ne lit aucun état de processus ; il traduit les modes fournis plutôt que de déduire l'architecture du serveur.
La calculatrice ne découvre pas l'identité d'un travailleur nginx
Inspectez chaque composant d'annuaire en tant que mode fourni distinct. Pour les répertoires, l'exécution permet un accès basé sur l'entrée et le nom, la lecture permet la liste et l'écriture permet de créer, renommer et supprimer des entrées. L'explication spécifique à la cible aide les réviseurs à déterminer si la classe établie en externe s'est exécutée sur un composant particulier sans prétendre inspecter le chemin lui-même.
Le navigateur ne passe pas de la racine à la racine Web. Il ne peut pas localiser un composant bloquant, confirmer son existence ou inspecter les ACL. Fournissez chaque mode de répertoire observé séparément, puis vérifiez l'objet final comme un fichier normal, où la lecture concerne le contenu plutôt que les listes. Cela interprète les preuves collectées au lieu de remplacer l'inspection du système de fichiers.
Les fichiers ont besoin de r, et rien de plus - pourquoi 644 est suffisant pour les fichiers statiques et pourquoi 755 sur les fichiers n'est pas la solution
Pour un fichier statique, 644 restitue rw-r--r--. Le propriétaire reçoit la lecture et l'écriture, tandis que le groupe et les autres reçoivent la lecture ; personne ne reçoit l'exécution. Cette conversion montre que le fichier lu et exécuté sont des bits distincts. La page n'a aucune base pour décider si un serveur particulier doit être exécuté, car la politique du serveur est absente.
Gardez les explications sur les fichiers et les répertoires distinctes. L'exécution de répertoire signifie l'accessibilité basée sur l'entrée et le nom, tandis que l'exécution de fichier standard signifie l'exécution d'un programme. La même case à cocher a donc une prose spécifique à la cible. La comparaison de 644 avec 755 clarifie les bits, mais ne peut pas diagnostiquer un 403 ou prescrire un mode universel sans configuration, identité, ACL et contexte de politique.
Exemple pratique : tracer /home/deploy/site/index.html — namei -l sur le chemin et la ligne ls -l qui révèle le bloqueur
Un exemple pris en charge commence après que les preuves de chemin ont été rassemblées ailleurs. Supposons que les composants du répertoire soient 755 et que le fichier final soit 644. La calculatrice affiche les répertoires sous la forme rwxr-xr-x, expliquant le groupe et les autres exécutions comme entrée et accessibilité. Il restitue le fichier sous la forme rw-r--r--, expliquant le groupe et les autres lectures comme accès au contenu.
Si un composant est 750, son autre triple est ---, tandis que le groupe reste r-x. Cette différence peut être importante, mais ne prouve pas que nginx en utilise d'autres. La route ne peut pas exécuter namei ou ls, donc des preuves externes doivent fournir des chemins et des modes. Il synchronise ensuite chaque représentation pour réduire les erreurs de transcription lors de la révision.
Exemple concret : inspecter les modes fournis pour chaque composant d'un chemin
Les décisions de propriété restent en dehors de la conversion de mode. Le panneau ne lit aucun propriétaire ou groupe et n'offre aucune opération chown ou chgrp. Il ne peut pas choisir entre le déploiement, la propriété d'un service ou d'un groupe partagé, ni évaluer le déplacement du contenu. Ces décisions nécessitent des preuves du système et de la charge de travail absentes des sources ; aucun mode généré ne peut remplacer ce contexte.
Une fois la propriété résolue ailleurs, comparez la façon dont les modes divisent l'accès. Le mode 750 donne les autorisations complètes au propriétaire, la lecture et l'exécution du groupe, et rien aux autres ; 755 ajoute d'autres lectures et exécutions. Cela reste conditionné à la connaissance de la classe ouvrière. L'aperçu de la commande inerte ne change pas de propriétaire et ne confirme pas l'accès au serveur.
Les choix de propriété restent externes à la conversion de mode
La configuration, la sélection d'index, le contrôle d'accès obligatoire et le comportement en amont ne sont pas diagnostiqués ici. Aucune source ne charge la configuration nginx, ne vérifie un URI ou un index, ne lit les journaux, ne contacte un amont ou n'observe SELinux ou AppArmor. La conversion correcte d'un mode fourni ne peut donc pas établir pourquoi nginx a renvoyé 403 ; les preuves du serveur doivent répondre à cette question.
Conserver cette distinction lorsqu'un mode semble suspect. Le panneau peut montrer qu'une classe de répertoire manque d'exécution ou qu'une classe de fichier manque de lecture, mais la pertinence dépend de la preuve d'identité et de chemin. Les bits permissifs ne peuvent pas non plus exclure d’autres causes. Indiquez exactement ce que le mode autorise, puis revenez aux diagnostics spécifiques au serveur.
La configuration, l'index, le MAC et les causes en amont ne sont pas diagnostiqués
L'accès au chemin peut dépendre de chaque composant, mais la calculatrice ne voit qu'une seule valeur fournie à la fois. Sa force réside dans un décodage précis : le texte octal, symbolique et les cases à cocher restent synchronisés, tandis que la prose de l'annuaire distingue le listing, la modification et la saisie. Il simplifie l'examen sans prétendre découvrir ni les composants ni le processus tentant d'y accéder.
Établissez l'identité du serveur et collectez les modes de chemin en dehors de cet itinéraire. Décodez chaque répertoire en tant que répertoire et l'objet final en tant que fichier normal, en vous concentrant sur la classe vérifiée en externe. Examinez séparément la configuration, les ACL et la stratégie obligatoire. La calculatrice valide l'arithmétique, mais ne peut pas identifier la cause d'un 403 ni vérifier un correctif.