Polkit エージェントかシークレットエージェントか：どのプロンプトが欠けているのか

設定に触れる前に、ダイアログの文言を最後まで読む。一方のプロンプトはマシンのネットワークを変更する権限を求め、もう一方は接続に必要なシークレットを求める。これらは別々のコンポーネントから来ており、別々の理由で失敗し、片方を直してももう片方は直らない。メッセージはどちらを扱っているのかを明示している。

VPN ではなく、操作が要求された理由にすぎないその名前から始める。

実際に欠けているのはどちらのプロンプトか？

ローカル認可のプロンプトは、このユーザーが特権操作を実行してよいかをデスクトップが尋ねているという意味だ。シークレットのプロンプトは、トンネルを構築する前に接続ストアがパスワード、鍵のパスフレーズ、またはトークンを必要としているという意味だ。前者にはセッション内の認証エージェントが応答し、後者にはネットワーク管理サービスが到達できるシークレットエージェントが応答する。メッセージが認証エージェントが見つからないと述べているなら、VPN のパスワードはまだ要求されていない。

問題を報告するとき、この順序が重要になる。起動の文脈、要求されたローカル操作、認可の結果、そして後続の接続エラーは四つの別々の事実であり、これらを混ぜると誰も行動できない報告になる。

Polkit エージェントはセッションの中にいる

Polkit は特権的なシステム操作を、それを要求する通常のプログラムから切り離し、ユーザーのセッション内のエージェントがその対話を提示する。軽量デスクトップ、素の端末から起動したランチャー、エージェントを失ったセッションは、いずれもその対話を利用できない状態にしうる。ポリシーが間違っていると決めつける前に、アプリケーションがどう起動されたかを確認する。テキストだけのセッションには、別のログインから借りたグラフィカルなものではなく、自身の対応エージェントが必要だ。

別のユーザーの環境からセッションバスのアドレスや表示変数をコピーすることは、認可の計画ではない。それは接続しているように見えながら、プロンプトに正しく応答できないセッションを生む。

シークレットエージェントは別のものを提供する

ネットワーク管理サービスは、自分では保存しない資格情報をシークレットエージェントに要求し、エージェントはその要求をユーザーに示す。独自の対話プロンプトを持つコマンドラインクライアントもそうしたエージェントの一つであり、デスクトップシェルは通常もう一つを提供する。シークレットを利用可能にしてもシステムネットワークを変更する権限は得られず、ローカル認可を修復しても欠けた資格情報は作られない。一つのワークフローが両方の答えを必要とすることがあり、その順序は常にこのとおりだ。

シークレットのダイアログが一度も現れないなら、polkit のポリシーではなく、サービスがどのエージェントに到達できるかを見る。

修復すべきはセッションで、特権レベルではない

VPN インターフェース全体を root で動かすのではなく、デスクトップの対応エージェントと起動時の統合を使う。すべてのユーザーに無条件のネットワーク管理を与えることや、認可サービスを無効化することは、欠けたダイアログを恒久的な穴と引き換えにする。管理された機器では、管理者が承認されたオペレーターを意図的に求めることがあり、正しい修正はその判断の範囲内で作業することだ。対応する権限の表示を確認し、現在のユーザーが何を要求できるかを見る。

ローカルの答えとゲートウェイの認証結果は二つの別の出来事であり、混ぜてはいけない。端末での対話的なシークレットプロンプトも、どれほど便利に感じられても、誰かを認可ポリシーから免除しない。

どのエージェントが、どのセッションで応答し、その後に何が起きたかを記録する。