Eine Datei, die der Webserver nicht schreiben kann, wird meist mit 777 repariert, und es klappt. Es heißt aber auch, dass jeder Prozess auf der Maschine - auch einer, den ein Angreifer gerade hochgeladen hat - sie überschreiben kann. Die eigentliche Frage ist nicht, welche Rechte gesetzt sind, sondern wem die Datei gehört.

Die richtige Anordnung

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

Ihnen gehören die Dateien, dem Webserver gehört die Gruppe; er kann alles lesen und nur die beiden Verzeichnisse beschreiben, die es brauchen.

Die führende 2 ist die Gruppenfalle

Das ist setgid. Ohne es bekommt eine im Verzeichnis angelegte Datei die eigene Gruppe des Erzeugers - eine vom Webserver hochgeladene Datei ist also für Sie nicht lesbar, und eine von Ihnen angelegte für ihn nicht schreibbar. Alles funktioniert, bis jemand anders eine Datei hinzufügt, und darum wirkt der Fehler zufällig.

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

umask entscheidet, was NEUE Dateien bekommen

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

Setzen Sie es für einen Daemon in der Service-Unit, nicht in Ihrem Shell-Profil, sonst gilt es nur für Dateien, die Sie von Hand anlegen.

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

Niemals 777

777 auf einem Upload-Verzeichnis, dazu ein Webserver, der dort PHP ausführt, ist der mit Abstand häufigste Weg, auf dem eine Website übernommen wird. Siehe Upload-Verzeichnis: niemals ausführbar.

Finden, was schon falsch ist

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