1.6 KiB

Raw Blame History

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 :

chmod 600 <fichier> immédiatement après création
ls -la <fichier> pour vérifier le résultat réel
Revérifier après tout cp/scp/tar — les permissions ne suivent pas toujours
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

1.6 KiB Raw Blame History