docs: runbook commun - permissions credentials/cles (piege 777)

common/permissions-credentials-cles-chmod.md

@@ -0,0 +1,29 @@
+# Permissions credentials/clés — piège 777 et règle transverse aux 3 instances
+
+**Date** : 2026-07-05
+**Portée** : commun (hermes-tt, hermes-nyora, hermes-perso)
+**Tags** : infra, securite, credentials, permissions, chmod
+
+## Problème rencontré
+Une clé privée WireGuard (config VPN KeepSolid, projet VPS Contabo/hermes-nyora) écrite dans
+un workspace s'est retrouvée en permissions **777** (rwxrwxrwx) alors que le HANDOFF de session
+affirmait "chmod 600". N'importe quel process/container avec accès au mount aurait pu lire
+la clé privée en clair. Le commentaire documenté ne garantissait rien sur l'état réel du fichier.
+
+## Cause
+Écriture du fichier sans vérification post-écriture. Un chmod mentionné dans une instruction
+ou un commentaire n'est pas un chmod exécuté.
+
+## Règle appliquée (désormais dans le skill partagé `nas-ops`, auto-tappé par les 3 instances)
+Après toute écriture d'un fichier contenant clé/token/mot de passe/certificat/config VPN :
+1. `chmod 600 <fichier>` immédiatement après création
+2. `ls -la <fichier>` pour vérifier le résultat réel
+3. Revérifier après tout `cp`/`scp`/`tar` — les permissions ne suivent pas toujours
+4. Ne jamais documenter un chmod sans l'avoir vérifié à l'instant T
+
+## Où c'est appliqué
+`bolbol/hermes-skills/skills/nas-ops/SKILL.md` — mis à jour le 05/07/2026, propagé
+automatiquement aux 3 instances (hermes-tt, hermes-nyora, hermes-perso) via le tap Gitea.
+
+## Lien
+Détail du cas d'origine : [hermes-nyora/vps-contabo-wireguard-qbittorrent-natif.md](../hermes-nyora/vps-contabo-wireguard-qbittorrent-natif.md)