Nginx permesso negato durante la lettura di upstream - anche quando eseguito come root

Question

Ho una app di flask in esecuzione sotto uWSGI dietro nginx.

*1 readv() failed (13: Permission denied) while reading upstream, client: 10.0.3.1, server: , request: "GET /some/path/constants.js HTTP/1.1", upstream: "uwsgi://unix:/var/uwsgi.sock:", host: "dev.myhost.com" 

Le autorizzazioni per la presa siano adeguati (in 666, e impostare lo stesso utente come nginx), infatti, anche quando corro nginx come root ho ancora ottenere questo errore.

L'app di flask/uwsgi sta inviando la richiesta correttamente. Ma non viene letto da Nginx. Questo è su Ubuntu Utopic Unicorn.

Qualsiasi idea in cui l'autorizzazione potrebbe essere negata se il processo nginx ha accesso completo al socket?

Come fattore di complicazione, questo server è in esecuzione in un contenitore in cui è installato Ubuntu 14.04. E questa configurazione funzionava ... ma di recente ho aggiornato l'host a 14.10 ... Posso capire perfettamente che questa potrebbe essere la causa del problema. Ma prima di eseguire il downgrade dell'host o aggiornare il contenitore, voglio capire perché.

Quando eseguo strace su un lavoratore che sta generando questo errore vedo la chiamata che sta facendo è qualcosa di simile:

readv(14, 0x7fffb3d16a80, 1)   = -1 EACCES (Permission denied) 

14 sembra essere il descrittore di file creato da questa chiamata di sistema

socket(PF_LOCAL, SOCK_STREAM, 0)  = 14 

Quindi non può leggere da un socket locale appena creato?

Answer 1

OK! Quindi il problema era, penso, relativo a this bug. Sembra che anche se l'apparmor non fosse configurato per impedire l'accesso ai socket all'interno dei contenitori, in realtà stava facendo qualcosa per impedirne la lettura (anche se non la creazione ...), quindi disattivare Apparmor per il contenitore (following these instructions) ha funzionato per risolverlo .

Le due linee rilevanti erano:

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start 

sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/

e aggiungendo

lxc.aa_profile = unconfined 

Nel file di configurazione contenitori.

NB: questi errori non sono stati registrati nei registri di apparmor.

Answer 2

Questo problema è stato probabilmente introdotto nel kernel 3.16, poiché non viene riprodotto in 14.04 con il kernel 3.13. Strano bug di apparmor era effettivamente responsabile per quello.

Purtroppo la soluzione di @ aychedee non ha funzionato per me. Nel mio caso ho dovuto aggiungere il seguente parametro docker run comando per sbarazzarsi del problema:

docker run --security-opt apparmor:unconfined ... 

Se qualcuno è a conoscenza quello che è lo stato attuale del problema, si prega di considerare l'aggiunta di commento sotto questa risposta :)