From 0ea8eb1cdee59c6381a8926d9b802daa6d546024 Mon Sep 17 00:00:00 2001 From: andre Date: Fri, 25 Sep 2026 12:47:06 +0100 Subject: [PATCH] =?UTF-8?q?docs(platform-tools):=20regista=20a=20tentativa?= =?UTF-8?q?=20revertida=20de=20apertar=20permiss=C3=B5es?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit config/cache/ e assets/img/seo/ passaram a volumes próprios (/srv/data/fitme.andmore.pt/{cache,seo}), mas o checkout continua 664/2775: o deploy-on-push corre como www-data dentro do pedido do webhook, não como deploy, e 644/2755 partiu a primeira push a seguir ("Permission denied" a criar um ficheiro novo). Documentado para a próxima vez que alguém for tentar isto outra vez. Co-Authored-By: Claude Sonnet 5 --- PLATFORM_TOOLS.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/PLATFORM_TOOLS.md b/PLATFORM_TOOLS.md index 752a95b..49f40f4 100644 --- a/PLATFORM_TOOLS.md +++ b/PLATFORM_TOOLS.md @@ -43,3 +43,14 @@ for that endpoint already resolves to the same `CLAUDE_GITEA/.auto-update-secrets` on Andre's machine), and `system_settings.auto_update_enabled = '1'`. Toggle it off from Sistema → Atualizar plataforma if a push needs to land without auto-deploying. + +**Why the checkout stays group-writable (664/2775, `deploy:www-data`):** the +webhook's `git pull` runs *inside the PHP request*, as `www-data`, not as +`deploy`. Tried tightening to 644/2755 on 2026-09-25 (audit 2.6) and the very +next push failed with "Permission denied" creating a new file — reverted +within minutes. `config/cache/` and `assets/img/seo/` (the app's only two +runtime-write targets inside the checkout besides `uploads/`/`logs/`/ +`backups/`, which already had their own volumes) got their own bind mounts +from `/srv/data/fitme.andmore.pt/` in `compose.yml`, same pattern fotografia +uses — but the checkout itself can't go read-only for `www-data` without +giving up deploy-on-push.