Monter un partage depuis Tunnelblick sans s’exécuter en root

Un AppleScript qui reste ouvert peut surveiller un profil Tunnelblick et monter un partage SMB en tant qu’utilisateur connecté, sans hook root ni sudo sans mot de passe.

Le client VPN a besoin d’une aide privilégiée pour reconfigurer le réseau, et ce fait est appliqué trop largement à tout ce qui l’entoure. Un script qui monte un partage de fichiers n’a pas besoin de root, car le partage appartient à la session de l’utilisateur connecté et aux identifiants de cet utilisateur. Sortir le montage du chemin privilégié supprime le besoin de règles sudo, de hooks root et de modifications des applications fournies. Ce qui reste est une petite applet qui reste ouverte, surveille un profil et fait une tentative.

Pourquoi cela relève de la session utilisateur

Un volume monté est une propriété de la session qui l’a monté. La session d’un autre utilisateur ne le voit pas, et un montage possédé par root se comporte différemment de celui créé par le Finder. Garder le montage dans la session utilisateur préserve cette sémantique.

Des assistants privilégiés existent pour les parties qui en ont réellement besoin : créer une interface de tunnel, modifier les routes, mettre à jour le résolveur. Monter un partage SMB ne fait pas partie de ces parties. Le traiter comme tel force un choix entre un sudo sans mot de passe et un script root qui s’exécute sans personne présente. Les deux sont des risques plus grands que le problème ne le justifie, et l’approche par session utilisateur évite entièrement ce choix.

Les hooks de connexion de Tunnelblick ne remplacent pas cela ici, car ils s’exécutent hors de la session de bureau et leur ordre par rapport aux scripts du client n’est pas défini. Interroger l’état depuis une applet utilisateur est un mécanisme plus petit, avec moins d’hypothèses.

Prouver d’abord à la main que le partage fonctionne

L’automatisation ne peut pas fournir une route, une permission ou un compte qui n’existe pas. Connectez le VPN manuellement et ouvrez le partage dans le Finder avant d’écrire le moindre script. Si cela échoue, le script échouera d’une manière plus déroutante.

Notez les trois valeurs que le script utilisera : le nom du profil exactement tel que Tunnelblick l’affiche, l’URL du partage et le nom du volume que le Finder affiche après le montage. Le nom du volume compte parce que la vérification d’un montage existant l’utilise, et une vérification fondée uniquement sur le nom est une garde de commodité, non une preuve de l’identité du serveur. Utilisez un nom unique sur la machine. Confirmez ensuite que le serveur répond, tout simplement.

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

La première commande prouve que le serveur répond, la deuxième que le nom du profil se résout, et la troisième montre à quoi ressemble un montage réussi. Consignez les trois avant d’automatiser quoi que ce soit.

Lire l’état du profil depuis Tunnelblick

Tunnelblick expose ses configurations et leurs états via AppleScript, et c’est le seul hook dont cette conception a besoin. L’état qui compte est la chaîne rapportée pour ce profil précis, pas la présence de l’application.

L’interrogation a des conséquences qu’il vaut la peine d’énoncer. Une reconnexion plus courte que l’intervalle peut passer inaperçue, et l’applet ne voit pas du tout la transition. C’est acceptable pour une garde de montage et inacceptable pour tout ce qui doit réagir à chaque événement. Si vous avez besoin de fidélité événementielle, c’est le mauvais mécanisme, et non un mécanisme qui aurait besoin d’une minuterie plus courte. Choisissez l’intervalle en gardant ce compromis à l’esprit.

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

Exportez-le comme application avec l’option de rester ouverte, puis lancez-la dans la session connectée plutôt que via sudo.

Monter une fois, puis cesser d’essayer

L’indicateur tentative est ce qui empêche cela de devenir une boucle qui devine les identifiants. Une fois que l’applet a essayé, elle attend que l’état de connexion change avant de réessayer.

Ce comportement est délibéré. Un partage qui refuse le montage le refuse généralement pour une raison qu’une nouvelle tentative ne peut pas corriger, et des tentatives répétées transforment une invite en un flot d’invites. L’indicateur est réinitialisé lorsque le profil quitte l’état connecté, si bien qu’une véritable reconnexion produit exactement une nouvelle tentative. Quitter et relancer l’applet le réinitialise aussi, et c’est la solution manuelle. Aucun des deux chemins ne masque un échec ; les deux le laissent visible dans le Finder.

Le script ne contient aucun mot de passe, et il devrait le rester. Laissez l’opération de montage demander, et laissez le trousseau faire ce que l’organisation prend en charge. Intégrer un identifiant dans une URL transforme un script de commodité en secret qu’il faut faire tourner.

Ce que l’assistant ne peut pas faire

Trois limites méritent d’être écrites à côté de l’applet. Il ne peut pas éjecter un volume occupé après une panne réseau, il ne peut pas garantir que le DNS et le serveur sont prêts quand l’état indique connecté, et il ne réagit pas à chaque reconnexion.

La première limite est la plus importante en pratique. Un partage dont le serveur disparaît laisse un volume qui semble monté et bloque à l’accès, et la correction polie consiste à terminer les opérations de fichiers et à éjecter avant une déconnexion planifiée. La deuxième explique la plupart des premières tentatives ratées : le tunnel est établi alors que le résolveur n’a pas encore suivi, alors attendez puis montez une fois à la main pour confirmer. La troisième est le compromis d’interrogation évoqué plus haut, et non un bogue à corriger.

Pour une machine sans surveillance ou un parc géré, cette conception est de la mauvaise forme. Utilisez une politique de montage gérée par l’administrateur au lieu d’étendre une applet de bureau en service privilégié.

Articles similaires