Les montages SSHFS appartiennent à l’utilisateur, pas au crochet VPN

L’hypothèse est facile à adopter et difficile à remarquer : un crochet de connexion VPN s’exécute en root, donc le montage qu’il lance devrait lui aussi être organisé en root. Ce raisonnement produit un répertoire d’équipe que l’utilisateur du bureau ne peut pas ouvrir, un montage qui disparaît au redémarrage du service déclencheur et une invite d’authentification dans un contexte où personne ne peut y répondre. Le crochet et le montage sont deux tâches différentes, et une seule des deux a besoin de privilèges.

Le mythe : le privilège réseau implique le privilège de montage

Lever une interface et s’authentifier auprès d’un serveur de fichiers sont des capacités sans rapport, et elles appartiennent normalement à des comptes différents. Le composant VPN a besoin de privilèges suffisants pour modifier les routes et les interfaces. Le compte du serveur de fichiers a besoin d’une clé ou d’un mot de passe, d’une décision sur la clé d’hôte et d’un répertoire personnel où monter. Confier les identifiants de la seconde tâche à la première identité, c’est ainsi qu’un service réseau finit par détenir la clé d’un utilisateur.

Sur un portable mono-utilisateur, ce peut être le même compte, et cette coïncidence n’est pas une conception.

Une fois qu’un crochet privilégié effectue le montage, trois choses tournent mal en silence. Le montage appartient à root, l’agent de l’utilisateur est absent de cet environnement, et les échecs apparaissent dans le journal du service réseau plutôt que dans la session qui s’en soucie. Rien de tout cela ne se répare en ajoutant des options à la commande de montage. Cela se répare en confiant la tâche à la session qui détient l’identité.

Pourquoi le montage appartient à l’utilisateur connecté

Un montage SSHFS est un montage FUSE détenu par le processus qui l’a créé, et l’accès suit cette propriété plutôt que le mode du répertoire parent. La référence recommande un utilisateur ordinaire avec un point de montage que cet utilisateur possède, et c’est précisément pourquoi un montage créé par un processus root est peu commode pour tous les autres. Un changement de permissions sur le point de montage n’y remédie pas, car l’obstacle est le propriétaire du montage lui-même.

Partez d’une base manuelle dans la session de l’utilisateur : un point de montage vide existant sous le répertoire personnel, un compte autorisé sur le serveur et une clé d’hôte déjà vérifiée par votre procédure approuvée. Montez-le une fois à la main et utilisez-le, car cela prouve que le chemin d’identité fonctionne avant qu’une automatisation existe. Notez ce dont la commande avait besoin : le nom du compte, le chemin d’export et le nom d’hôte privé. Conservez ce contexte exact pour la version automatisée, car un montage manuel fonctionnel est la spécification que le déclencheur doit reproduire.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Traitez chaque nom et chaque chemin de cette ligne comme un espace réservé, y compris le compte et l’export. Le mot de passe d’un compte VPN n’est pas automatiquement l’identifiant du compte de stockage.

Ce que le déclencheur doit demander à la session

La disposition prise en charge est une requête de l’événement réseau vers la session de l’utilisateur, et non un identifiant emprunté. Limitez le déclencheur à la connexion visée, par nom ou par UUID, plutôt qu’à toute interface qui se trouve s’appeler tun0. Ce seul changement empêche un second profil, un tunnel de test ou la session de débogage d’un collègue de lancer un montage.

L’action côté session doit chercher le montage existant prévu, puis faire une seule tentative bornée.

Ne réessayez pas à chaque interrogation et ne continuez pas à demander un identifiant tant que le serveur est injoignable, car les deux transforment une panne passagère en verrouillage de compte. Un service sans surveillance est une conception distincte, avec ses propres identifiants approuvés et sa propre vérification d’hôte dans son propre contexte d’exécution, et il ne peut pas compter que quelqu’un ait déverrouillé un agent graphique. Décidez lequel des deux vous construisez avant de choisir où vit le code. L’essentiel de la confusion ici vient de construire l’un et d’attendre l’autre.

La déconnexion est un événement du système de fichiers, pas un événement du crochet

Une déconnexion planifiée devrait terminer les opérations de fichiers et démonter depuis la session de l’utilisateur qui monte avec la commande prise en charge pour ce type de système de fichiers. Forcer un détachement pour qu’un crochet revienne vite, c’est ainsi que les applications perdent leur répertoire de travail et que les utilisateurs perdent confiance dans l’automatisation. Un montage occupé a besoin d’une décision au niveau de l’application, comme fermer le fichier ou arrêter l’écriture, pas d’un signal plus fort. Le statut de sortie du crochet n’est pas ce qui est optimisé.

fusermount3 -u "$HOME/mnt/team"

La perte inattendue est un autre cas, et SSHFS documente qu’une opération interrompue peut se bloquer pendant que le transport se reconnecte.

L’option de reconnexion rétablit le transport, et les fichiers ouverts avant cette reconnexion peuvent encore renvoyer des erreurs et devoir être rouverts. Un VPN qui revient ne prouve rien sur les descripteurs antérieurs ni sur le travail non enregistré. Choisissez le comportement voulu en cas de panne — pause, affichage d’une erreur ou remontage volontaire — et testez-le avec des fichiers jetables avant que quoi que ce soit en dépende.