# 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)