Un fichier que le serveur web ne peut pas écrire se répare d'ordinaire avec 777, et ça marche. Cela veut aussi dire que n'importe quel processus de la machine - y compris celui qu'un attaquant vient de téléverser - peut le réécrire. La vraie question n'est pas quelles sont les permissions, mais à qui appartient le fichier.

L'arrangement correct

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

Vous possédez les fichiers, le serveur web possède le groupe, et il peut tout lire et n'écrire que dans les deux répertoires qui en ont besoin.

Le 2 de tête, c'est le piège du groupe

C'est setgid. Sans lui, un fichier créé dans le répertoire prend le groupe propre de son créateur : un fichier téléversé par le serveur web n'est donc pas lisible par vous, et un fichier que vous créez n'est pas modifiable par lui. Tout marche jusqu'à ce que quelqu'un d'autre ajoute un fichier, et c'est pour cela que la panne paraît aléatoire.

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

umask décide de ce que reçoivent les NOUVEAUX fichiers

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

Réglez-le dans l'unité de service pour un démon, pas dans votre profil de shell, sinon il ne vaut que pour les fichiers que vous créez à la main.

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

Jamais 777

777 sur un répertoire de téléversement, plus un serveur web disposé à y exécuter du PHP, est de loin la façon la plus courante dont un site est pris. Voyez répertoire de téléversement : jamais exécutable.

Trouver ce qui est déjà faux

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