Permissions shell

Pourquoi les permissions shell sont importantes

Un terminal donne potentiellement accès à bien plus qu’un seul fichier. Une commande peut lire l’état d’un projet, écrire sur disque, lancer un processus, installer un paquet, modifier Git, toucher une configuration ou communiquer avec un service externe.

Pour cette raison, le fait de démarrer OrbitWake dans un projet ne doit pas être interprété comme une autorisation générale d’exécuter n’importe quelle commande disponible sur la machine.

Le modèle de permission doit rester proportionné à l’action : plus une commande est susceptible de modifier l’environnement ou de produire un effet durable, plus le niveau de contrôle attendu doit être élevé.

Commandes de lecture et d’inspection

Certaines commandes servent principalement à comprendre l’environnement courant. Elles peuvent afficher le répertoire, lister des fichiers, lire un état Git ou montrer des informations sur un projet sans modifier directement les données.

$ pwd
$ ls
$ git status
$ git diff

Ces commandes sont des exemples standard du shell ou de Git. Elles ne constituent pas une liste d’autorisation OrbitWake et ne garantissent pas qu’une commande donnée sera exécutée automatiquement par le produit.

Commandes qui modifient l’environnement

D’autres commandes écrivent sur disque, déplacent des fichiers, installent des dépendances, modifient une configuration ou changent l’état Git. Elles doivent être traitées séparément des opérations de lecture.

Une modification locale peut être bénigne ou importante selon le projet. Écrire dans un fichier temporaire n’a pas le même impact que changer un fichier de production, une configuration d’infrastructure ou un script de déploiement.

Le produit doit donc évaluer l’action réelle et pas seulement le nom de la commande. Une même commande peut être sûre dans un contexte et risquée dans un autre.

Niveaux de risque

Pour raisonner sur les permissions, il est utile de distinguer plusieurs familles d’actions.

Ce tableau décrit un principe de sécurité et non une matrice de permissions déjà implémentée. Les règles exactes d’OrbitWake seront documentées lorsqu’elles seront stabilisées.

Quand demander une confirmation

Une confirmation explicite est particulièrement importante lorsqu’une action peut supprimer des données, écraser un changement existant, publier vers un remote, déployer en production, modifier des permissions ou produire un coût externe.

Pour les tâches à risque, OrbitWake doit présenter suffisamment de contexte pour que l’utilisateur puisse comprendre ce qui va changer avant l’exécution.

La confirmation ne doit pas être remplacée par une formulation vague. Elle doit porter sur l’action précise : quels fichiers, quelle branche, quel environnement ou quelle ressource sera touché.

Le répertoire courant reste une limite importante

Lancer OrbitWake depuis le bon projet aide à réduire la surface de travail et à clarifier le contexte. Commencez depuis le dossier qui représente réellement le projet concerné.

$ cd /chemin/vers/votre-projet
$ orbitwake

Le répertoire courant ne doit toutefois pas être considéré comme une sandbox de sécurité garantie. Une commande shell peut techniquement référencer des chemins en dehors de ce dossier. Les permissions du produit doivent donc rester la véritable barrière de contrôle.

Variables d’environnement, secrets et sortie de commandes

Une commande peut afficher ou consommer des variables d’environnement, des tokens, des clés d’API ou d’autres informations sensibles. Ces données doivent être traitées avec plus de prudence que du texte de projet ordinaire.

Évitez de demander l’affichage de secrets complets si ce n’est pas nécessaire. Les sorties de commandes doivent être limitées aux informations utiles à la tâche et ne pas être recopiées inutilement dans des logs, messages ou fichiers.

Les mécanismes exacts de masquage, redaction et politique de secrets d’OrbitWake seront documentés lorsqu’ils seront confirmés.

Workflow recommandé avant une commande sensible

Avant d’exécuter une commande susceptible de modifier le projet, commencez par inspecter l’état courant. Pour un projet Git, un workflow simple peut ressembler à ceci :

$ git status
$ git branch --show-current
$ git diff
$ orbitwake

Après le lancement, décrivez clairement la tâche et son niveau d’impact. Pour une modification importante, vérifiez la portée proposée avant l’écriture ou l’exécution.

Bonnes pratiques

Commencez par les actions les moins invasives : lecture, inspection, explication et plan. Passez à l’écriture ou à l’exécution uniquement lorsque la tâche l’exige.

Préservez les changements locaux qui existaient déjà. Ne réinitialisez pas automatiquement un fichier, une branche ou un environnement simplement parce qu’il complique la tâche.

Pour les commandes d’installation, de build, de migration ou de déploiement, vérifiez l’environnement ciblé et les effets attendus avant l’exécution.

Pour les opérations sensibles, préférez une action précise et limitée plutôt qu’une commande large qui touche plus de ressources que nécessaire.

Ce qui reste à documenter

La syntaxe exacte d’approbation, les politiques persistantes de permission, les catégories de commandes automatiquement autorisées, les sandbox éventuelles, les règles réseau, les restrictions de chemins, le traitement des processus longs et la gestion détaillée des secrets ne sont pas encore publiés comme contrat stable.

Cette page définit donc les principes de sécurité attendus sans inventer un mécanisme de permission qui n’a pas encore été confirmé dans le produit.

Étapes suivantes

Continuez avec Sessions pour comprendre comment une session CLI organise le contexte de travail, ce qui peut être conservé pendant l’interaction et quelles limites doivent rester explicites entre deux lancements.