Strumenti per sviluppatori · Calcolatore Chmod
Correzione di nginx 403 Forbidden: i permessi di file e directory che contano
· Perché è importante
chmod unix controllo degli accessi
Un 403 da nginx è spesso un problema del file system, non un problema di configurazione. Questo post mostra come verificare con quale utente nginx viene eseguito e di quali bit ha bisogno su ogni directory nel percorso.
403 su un sito statico che funzionava localmente: i file provenivano da /home/deploy e nginx dice vietato per ogni URL
Un nginx 403 può coinvolgere bit di modalità, ma questo percorso non è in grado di identificarne la causa. Il calcolatore non ha integrazione nginx, log, parser di configurazione, ricerca di processi o path walker. Risponde a domande più ristrette: se una classe di directory è stata eseguita e se una classe di file regolari ha letto, aiutando a interpretare le prove raccolte altrove.
Inizia con modalità esatte osservate su ciascun componente del percorso anziché assumere valori predefiniti. Entra in ciascuna modalità e scegli il tipo di bersaglio. Il testo simbolico, le caselle di controllo e la prosa espongono i permessi della classe e confermano la conversione, ma non possono mostrare che nginx ha tentato l'accesso, quale identità ha utilizzato o se i permessi del filesystem hanno prodotto la risposta.
Un 403 può coinvolgere bit di modalità, ma questo percorso non è in grado di identificarne la causa
La calcolatrice non è in grado di scoprire l'identità di un lavoratore nginx. Modella il proprietario, il gruppo e altre classi, ma non i nomi utente, i processi o le appartenenze. Una modalità come rwxr-xr-x quindi non dice nulla sul fatto che un lavoratore possieda l'oggetto, appartenga al suo gruppo o rientri in un altro. L'ispezione esterna deve stabilire tale classificazione.
La scoperta dell'identità deve precedere le affermazioni sui bit rilevanti. Una volta stabilita la classe applicabile, la matrice mostra letto come 4, scritto come 2 ed eseguito come 1. Prima di allora, modificare il gruppo o altro è un'ipotesi. Il percorso non legge lo stato del processo; traduce le modalità fornite anziché dedurre l'architettura del server.
La calcolatrice non rileva l'identità di un lavoratore nginx
Ispezionare ciascun componente della directory come modalità fornita separata. Per le directory, l'esecuzione consente l'accesso in base al nome e alle voci, la lettura consente l'elenco e la scrittura consente la creazione, la ridenominazione e l'eliminazione delle voci. La spiegazione specifica dell'obiettivo aiuta i revisori a determinare se la classe stabilita esternamente è stata eseguita su un particolare componente senza la pretesa di ispezionare il percorso stesso.
Il browser non cammina da root a web root. Non può individuare un componente di blocco, confermarne l'esistenza o ispezionare gli ACL. Fornire ogni modalità di directory osservata separatamente, quindi controllare l'oggetto finale come un file normale, dove la lettura riguarda i contenuti piuttosto che gli elenchi. Questo interpreta le prove raccolte invece di sostituire l'ispezione del filesystem.
I file hanno bisogno di r e niente di più: perché 644 è sufficiente per i file statici e perché 755 sui file non è la soluzione
Per un file statico, 644 esegue il rendering rw-r--r--. Il proprietario riceve lettura e scrittura, mentre il gruppo e gli altri ricevono lettura; nessuno riceve l'esecuzione. Questa conversione mostra che la lettura e l'esecuzione del file sono bit separati. La pagina non ha basi per decidere se un particolare server deve essere eseguito, perché la politica del server è assente.
Mantenere distinte le spiegazioni di file e directory. L'esecuzione della directory indica la raggiungibilità basata su voci e nomi, mentre l'esecuzione di file regolari significa l'esecuzione di un programma. La stessa casella di controllo ha quindi una prosa specifica per target. Il confronto tra 644 e 755 chiarisce alcuni bit, ma non può diagnosticare un 403 o prescrivere una modalità universale senza configurazione, identità, ACL e contesto politico.
Esempio realizzato: tracciare /home/deploy/site/index.html — namei -l sul percorso e la riga ls -l che rivela il bloccante
Un esempio supportato inizia dopo che le prove del percorso sono state raccolte altrove. Supponiamo che i componenti della directory siano 755 e il file finale sia 644. La calcolatrice visualizza le directory come rwxr-xr-x, spiegando gruppo e altre esecuzioni come voce e raggiungibilità. Rende il file come rw-r--r--, spiegando il gruppo e altre letture come accesso al contenuto.
Se un componente è 750, la sua altra tripla è ---, mentre il gruppo rimane r-x. Questa differenza può essere importante, ma non dimostra che nginx ne usi altri. Il percorso non può eseguire namei o ls, quindi prove esterne devono fornire percorsi e modalità. Quindi sincronizza ogni rappresentazione per ridurre gli errori di trascrizione durante la revisione.
Esempio realizzato: ispeziona le modalità fornite per ciascun componente di un percorso
Le decisioni sulla proprietà rimangono esterne alla conversione della modalità. Il pannello non legge alcun proprietario o gruppo e non offre operazioni di chown o chgrp. Non può scegliere tra distribuzione, servizio o proprietà di un gruppo condiviso, né valutare lo spostamento dei contenuti. Tali decisioni richiedono prove del sistema e del carico di lavoro assenti dalle fonti; nessuna modalità generata può sostituire quel contesto.
Una volta risolta la proprietà altrove, confrontare il modo in cui le modalità dividono l'accesso. La modalità 750 fornisce autorizzazioni di proprietario completo, lettura ed esecuzione del gruppo e niente ad altri; 755 aggiunge altre operazioni di lettura ed esecuzione. Ciò rimane subordinato alla conoscenza della classe operaia. L'anteprima del comando inerte non cambia la proprietà né conferma l'accesso al server.
Le scelte di proprietà rimangono esterne alla conversione della modalità
Qui non vengono diagnosticati la configurazione, la selezione dell'indice, il controllo di accesso obbligatorio e il comportamento upstream. Nessuna sorgente carica la configurazione nginx, controlla un URI o un indice, legge i log, contatta un upstream o osserva SELinux o AppArmor. La conversione corretta di una modalità fornita pertanto non può stabilire perché nginx ha restituito 403; le prove del server devono rispondere a questa domanda.
Mantieni questa distinzione quando una modalità appare sospetta. Il pannello può mostrare che una classe di directory non è in esecuzione o una classe di file non è in lettura, ma la rilevanza dipende dall'identità e dall'evidenza del percorso. Inoltre, i bit permissivi non possono escludere altre cause. Indica esattamente cosa consente la modalità, quindi torna alla diagnostica specifica del server.
Configurazione, indice, MAC e cause a monte non vengono diagnosticate
L'accesso al percorso può dipendere da ogni componente, tuttavia la calcolatrice vede un valore fornito alla volta. Il suo punto di forza è la decodifica accurata: il testo ottale, simbolico e le caselle di controllo rimangono sincronizzati, mentre la prosa della directory distingue l'elenco, la modifica e l'immissione. Semplifica la revisione senza pretendere di scoprire i componenti o il processo che tenta l'accesso.
Stabilire l'identità del server e raccogliere le modalità di percorso al di fuori di questo percorso. Decodifica ogni directory come directory e l'oggetto finale come un file normale, concentrandosi sulla classe verificata esternamente. Esaminare separatamente la configurazione, gli ACL e i criteri obbligatori. La calcolatrice convalida i calcoli aritmetici, ma non è in grado di identificare la causa di 403 o di verificare una soluzione.