Agent Polkit ou agent secret : quelle invite manque ?

Lisez le texte du dialogue avant de toucher à la moindre configuration. Une invite demande l’autorisation de modifier le réseau de la machine ; l’autre demande le secret dont une connexion a besoin. Elles viennent de composants différents, échouent pour des raisons différentes, et réparer l’une ne répare jamais l’autre. Le message nomme celle à laquelle vous avez affaire.

Partez de ce nom, et non du VPN, qui n’est que la raison pour laquelle l’opération a été demandée.

Quelle invite vous manque réellement ?

Une invite d’autorisation locale signifie que le bureau demande si cet utilisateur peut effectuer une opération privilégiée. Une invite de secret signifie que le magasin de connexions a besoin d’un mot de passe, d’une phrase de passe de clé ou d’un jeton avant que le tunnel puisse être construit. La première est traitée par un agent d’authentification de votre session ; la seconde par un agent secret que le service de gestion du réseau peut joindre. Si le message indique qu’aucun agent d’authentification n’a été trouvé, aucun mot de passe VPN n’a encore été demandé.

Cet ordre compte lorsque vous signalez le problème. Le contexte de lancement, l’opération locale demandée, le résultat de l’autorisation et toute erreur de connexion ultérieure sont quatre faits distincts, et les confondre produit un rapport sur lequel personne ne peut agir.

L’agent Polkit vit dans votre session

Polkit garde une opération système privilégiée séparée du programme ordinaire qui la demande, et un agent dans la session de l’utilisateur présente cette interaction. Un bureau léger, un lanceur démarré depuis un terminal nu ou une session qui a perdu son agent peuvent tous rendre cette interaction indisponible. Vérifiez comment l’application a été lancée avant de supposer que la politique est erronée. Une session uniquement textuelle a besoin de son propre agent pris en charge, pas d’un agent graphique emprunté à une autre connexion.

Copier des adresses de bus de session ou des variables d’affichage depuis l’environnement d’un autre utilisateur n’est pas un plan d’autorisation. Cela produit une session qui semble connectée et qui ne peut toujours pas répondre correctement à l’invite.

L’agent secret fournit autre chose

Le service de gestion du réseau demande à un agent secret des identifiants qu’il ne stocke pas, et l’agent montre cette demande à l’utilisateur. Un client en ligne de commande avec sa propre invite interactive est un tel agent ; un shell de bureau en fournit généralement un autre. Rendre un secret disponible n’accorde pas l’autorité de modifier le réseau du système, et réparer l’autorisation locale ne crée pas un identifiant manquant. Un même flux de travail peut avoir besoin des deux réponses, et toujours dans cet ordre.

Si l’invite de secret n’apparaît jamais, regardez quel agent le service peut joindre plutôt que la politique polkit.

Réparez la session, pas le niveau de privilège

Utilisez l’agent pris en charge du bureau et l’intégration au démarrage au lieu d’exécuter toute l’interface VPN en root. Accorder à chaque utilisateur une administration réseau inconditionnelle, ou désactiver le service d’autorisation, échange une invite manquante contre un trou permanent. Sur un équipement géré, l’administrateur peut exiger délibérément un opérateur approuvé, et la bonne correction est de travailler dans cette décision. Consultez la vue des permissions prises en charge pour voir ce que l’utilisateur actuel peut demander.

Ne fusionnez pas la réponse locale dans le résultat d’authentification de la passerelle ; ce sont deux événements. Une invite de secret interactive dans un terminal n’exempte personne de la politique d’autorisation, aussi pratique qu’elle paraisse.

Notez quel agent a répondu, dans quelle session, et ce qui s’est passé ensuite.