DSH VPS — defaultPreset danger-full-access par défaut + piège `docker compose up -d`

Instance auteur : hermes-nyora (vérification) + Claude (exécution, correctif ponctuel) Date : 2026-08-24 Tags : dsh, vps-contabo, docker, permissions, securite Statut : clos, vérifié en direct après redémarrage

Problème

permission.defaultPreset dans $DSH_HOME/settings.yaml était sur danger-full-access (accès fichiers complet, aucune approbation) — valeur héritée du premier déploiement, jamais durcie. Toute nouvelle session dsh-vps héritait de ce défaut, y compris une éventuelle session cordis (auto-modification du runtime) ouverte sans intervention manuelle. Seule la session active de Nabil avait été basculée à la main sur workspace-write via l'UI — le défaut global, lui, restait dangereux.

Ce qui a été vérifié avant d'agir (pas supposé)

Piège potentiel identifié par hermes-nyora avant validation : entrypoint.sh pourrait-il re-scaffolder settings.yaml à chaque boot et écraser le fix (même bug que le SKILL.md session-memory mort) ? Vérifié : le bloc d'écriture est gardé par if [ ! -f "$DSH_HOME/settings.yaml" ] — le fichier existe déjà dans le volume nommé dsh_vps_home, ce bloc ne s'exécute donc jamais au redémarrage. Le fix tient.
Valeur littérale exacte : vérifiée dans le JS compilé de @deepseek-ai/dsh-permission-presets (pas dans la doc) — la table de presets par défaut du module contient exactement "workspace-write": { sandbox: "workspace-write", approval: "ask" }. Orthographe confirmée avant application.

Piège technique dans la procédure initiale

docker compose up -d dsh-vps ne recharge PAS un conteneur déjà démarré dont seul le contenu d'un volume monté a changé (aucun changement du côté image/compose/env) — la commande est un no-op dans ce cas précis. Il faut docker compose restart dsh-vps pour que le process relise settings.yaml au démarrage.

Solution appliquée

# Backup (le fichier vit dans un volume nommé, pas un bind mount — passer par docker exec)
sudo docker exec dsh-vps sh -c "cp \$DSH_HOME/settings.yaml \$DSH_HOME/settings.yaml.bak-defaultpreset-20260824"

# Modification
sudo docker exec dsh-vps sh -c 'sed -i "s/defaultPreset: danger-full-access/defaultPreset: workspace-write/" $DSH_HOME/settings.yaml'

# Rechargement correct (pas up -d)
cd /home/dsh-agent/dsh-vps && sudo docker compose restart dsh-vps

Vérification

docker exec dsh-vps sh -c 'grep -A1 "^permission:" $DSH_HOME/settings.yaml'
# attendu, APRÈS redémarrage : defaultPreset: workspace-write (persistant, pas juste avant restart)

docker ps --filter name=dsh-vps --format "{{.Status}}"
# attendu : Up, pas de crash loop

curl -sk -o /dev/null -w "%{http_code}\n" https://<tailscale-ip>:8900/
# attendu : 401 (proxy + service toujours sains)

Résultat réel : workspace-write confirmé après redémarrage, conteneur up, proxy toujours en 401 — rien de cassé.

Leçon générale, transverse à tout déploiement DSH

Toujours vérifier permission.defaultPreset après un premier déploiement — le défaut du produit n'est pas nécessairement le défaut souhaité pour une instance exposée. Et pour toute modification d'un fichier vivant dans un volume nommé (pas un bind mount visible côté host) : docker compose restart <service>, jamais up -d, si rien d'autre n'a changé dans le compose/l'image.

Références

Runbook associé : hermes-nyora/dsh-vps-pnpm-plugins-bloques.md
Note NyoraNotes : dsh/dsh-vps-audit-capacite-plugins-mcp-et-memoire-persistante.md, dsh/dsh-vps-bridge-mcp-context-hub-verifie-fonctionnel-isolation-testee.md

3.7 KiB Raw Blame History

DSH VPS — defaultPreset danger-full-access par défaut + piège docker compose up -d