La soluzione pubblicata da bgles è perfetta per me in termini di impostazione corretta delle autorizzazioni inizialmente (utilizzo il secondo metodo), ma presenta ancora potenziali problemi per Laravel.
Per impostazione predefinita, Apache creerà file con autorizzazioni 644. Quindi è praticamente tutto nello spazio di archiviazione /. Quindi, se elimini i contenuti di archiviazione / framework / viste, quindi accedi a una pagina tramite Apache scoprirai che la vista cache è stata creata come:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Se esegui "servizio artigianale" e accedi a una pagina diversa, otterrai autorizzazioni diverse poiché CLI PHP si comporta in modo diverso da Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Di per sé questo non è un grosso problema in quanto non lo farai nella produzione. Ma se Apache crea un file che successivamente deve essere scritto dall'utente, fallirà. E questo può valere per i file della cache, le viste memorizzate nella cache e i registri durante la distribuzione utilizzando un utente e un artigiano registrati. Un semplice esempio di "cache artigianale: clear" che non riuscirà a eliminare i file della cache che sono www-data: www-data 644.
Questo può essere parzialmente mitigato eseguendo comandi artigianali come www-data, quindi eseguirai / esegui lo script di tutto come:
sudo -u www-data php artisan cache:clear
Oppure eviterai la noiosità di questo e lo aggiungerai ai tuoi .bash_aliases:
alias art='sudo -u www-data php artisan'
Questo è abbastanza buono e non influisce in alcun modo sulla sicurezza. Ma su macchine di sviluppo, l'esecuzione di script di test e risanamento lo rende ingombrante, a meno che tu non voglia impostare alias per usare 'sudo -u www-data' per eseguire phpunit e tutto il resto con cui controlli le tue build che potrebbe causare la creazione di file.
La soluzione è seguire la seconda parte dei consigli di bgles e aggiungere quanto segue a / etc / apache2 / envvars e riavviare (non ricaricare) Apache:
umask 002
Questo costringerà Apache a creare file come 664 per impostazione predefinita. Di per sé, ciò può presentare un rischio per la sicurezza. Tuttavia, negli ambienti Laravel per lo più discussi qui (Homestead, Vagrant, Ubuntu) il server Web funziona come dati www dell'utente sotto i dati www del gruppo. Pertanto, se non autorizzi arbitrariamente gli utenti a unirsi al gruppo www-data, non dovrebbero esserci rischi aggiuntivi. Se qualcuno riesce a uscire dal server web, ha comunque il livello di accesso ai dati www, quindi nulla va perso (anche se questo non è l'atteggiamento migliore nei confronti della sicurezza). Quindi in produzione è relativamente sicuro e su una macchina di sviluppo per singolo utente non è un problema.
Alla fine, poiché l'utente si trova nel gruppo www-data e tutte le directory che contengono questi file sono g + s (il file viene sempre creato nel gruppo della directory padre), tutto ciò che viene creato dall'utente o da www-data sarà r / w per l'altro.
E questo è l'obiettivo qui.
modificare
Indagando sull'approccio sopra descritto per impostare ulteriormente le autorizzazioni, sembra ancora abbastanza buono, ma alcune modifiche possono aiutare:
Per impostazione predefinita, le directory sono 775 e i file sono 664 e tutti i file hanno il proprietario e il gruppo dell'utente che ha appena installato il framework. Quindi supponiamo che iniziamo da quel punto.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
La prima cosa che facciamo è bloccare l'accesso a tutti gli altri e rendere il gruppo come www-data. Solo il proprietario e i membri dei dati www possono accedere alla directory.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Per consentire al server web di creare services.json e compiled.php, come suggerito dalla guida ufficiale all'installazione di Laravel. L'impostazione del bit sticky di gruppo significa che questi saranno di proprietà del creatore con un gruppo di dati www.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Facciamo la stessa cosa con la cartella di archiviazione per consentire la creazione di file di cache, registro, sessione e visualizzazione. Usiamo find per impostare esplicitamente le autorizzazioni della directory in modo diverso per directory e file. Non è stato necessario farlo in bootstrap / cache in quanto non vi sono (normalmente) sotto-directory.
Potrebbe essere necessario riapplicare eventuali flag eseguibili, eliminare il fornitore / * e reinstallare le dipendenze del compositore per ricreare collegamenti per phpunit et al, ad esempio:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
Questo è tutto. Fatta eccezione per la umask per Apache spiegata sopra, questo è tutto ciò che è necessario senza rendere l'intero projectroot scrivibile dai dati www, che è ciò che accade con altre soluzioni. Quindi è leggermente più sicuro in questo modo in quanto un intruso in esecuzione come www-data ha un accesso in scrittura più limitato.
fine modifica
Modifiche per Systemd
Questo vale per l'uso di php-fpm, ma forse anche per altri.
Il servizio standard di systemd deve essere sovrascritto, umask impostato nel file override.conf e il servizio riavviato:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777sia troppa libertà, perché include tutte le autorizzazioni per tutti.