Un file che il server web non riesce a scrivere di solito si aggiusta con 777, e funziona. Vuol dire anche che qualsiasi processo sulla macchina - compreso quello che un aggressore ha appena caricato - può riscriverlo. La domanda vera non è quali siano i permessi, ma di chi sia il file.

La disposizione corretta

sudo chown -R sara:www-data /var/www/site
sudo find /var/www/site -type d -exec chmod 2750 {} \;
sudo find /var/www/site -type f -exec chmod 640 {} \;

# only what genuinely must be written
sudo chmod -R 2770 /var/www/site/storage /var/www/site/uploads

I file sono suoi, il gruppo è del server web, e quello può leggere tutto e scrivere soltanto nelle due directory che ne hanno bisogno.

Il 2 davanti è la trappola del gruppo

Quello è setgid. Senza, un file creato dentro la directory prende il gruppo di chi lo ha creato: così un file caricato dal server web lei non lo può leggere, e uno creato da lei quello non lo può scrivere. Tutto funziona finché qualcun altro non aggiunge un file, ed è per questo che il guasto sembra casuale.

sudo chmod g+s /var/www/site/uploads
ls -ld /var/www/site/uploads      # drwxrws--- - the s is the setgid bit

umask decide che cosa ricevono i file NUOVI

umask            # 0022 typical: new files 644, new dirs 755
umask 0007       # files 660, dirs 770 - nothing for others

Per un demone lo imposti nella unit del servizio, non nel profilo della sua shell, altrimenti vale solo per i file che crea a mano.

# /etc/systemd/system/app.service
[Service]
UMask=0007

Mai 777

777 su una directory di caricamento più un server web disposto a eseguirvi PHP è di gran lunga il modo più comune in cui un sito viene preso. Veda directory dei caricamenti: mai eseguibile.

Trovi ciò che è già sbagliato

find /var/www -perm -o=w -not -type l | head -20