web-dev-qa-db-ja.com

パスワードがGNOMEキーリングに保持されている場合、NetworkManagerはWiFiネットワークへの自動接続に失敗します

デフォルトでは、NetworkManagerはWiFiパスワードをプレーンテキストで_*.nmconnection_内の_/etc/NetworkManager/system-connections/_ファイルに保存します。これは私には受け入れられないので、_nm-connection-editor_を使用して接続を編集することにしました。そこで、_Store the password only for this user_オプションをチェックしました。これには、パスワードをプレーンテキストではなくGNOMEキーリングに保存する効果があります。

ただし、このソリューションには問題があります。NetworkManagerは、コンピューターの起動時にsystemdユニットとして起動されます。現時点では、GNOMEキーリングはまだ開始されていません。ログインに成功すると、後でディスプレイマネージャーによって開始され、ユーザーパスワード（キーリングのパスワードと同じ）で自動的にロックが解除されます。したがって、明らかに、NetworkManagerはキーリングからのパスワードのフェッチに失敗し、次のログを出力します。

NetworkManager[610]: <warn> [1565208122.6857] device (wlp2s0): no secrets: No agents were available for this request.

ログインした後、WiFi接続がありません。 nmアプレットをクリックして、WiFiネットワークを選択する必要があります。この後接続されますが、自動的に発生した方がいいと思います。

構成に問題がありますか？もしそうなら、どうすればそれを修正できますか？

完全を期すために、ここに私の構成があります：

  • OS：Arch Linux
  • ディスプレイマネージャー：SDDM
  • ウィンドウマネージャー：i3
networkingarch-linuxsystemdwifi
1
rubix_addict

NetworkManagerのソースコードを分析したところ、問題が見つかりました。 NetworkManagerは、キーリングからシークレットを取得できない場合、接続の自動接続をブロックします。この動作は構成不可能であり、nm-policy.cにハードコードされているようです。

https://github.com/NetworkManager/NetworkManager/blob/master/src/nm-policy.c

1830行目の近くに、次のコードがあります。

if (nm_device_state_reason_check (reason) == NM_DEVICE_STATE_REASON_NO_SECRETS) {
    /* ... */
    con_v = nm_settings_connection_get_last_secret_agent_version_id (sett_conn);
    if (   con_v == 0
        || con_v == nm_agent_manager_get_agent_version_id (priv->agent_mgr))
            block_no_secrets = TRUE;
}

if (block_no_secrets) {
    _LOGD (LOGD_DEVICE, "connection '%s' now blocked from autoconnect due to no secrets",
        nm_settings_connection_get_id (sett_conn));
        nm_settings_connection_autoconnect_blocked_reason_set (sett_conn, NM_SETTINGS_AUTO_CONNECT_BLOCKED_REASON_NO_SECRETS, TRUE);
}

この動作をハックしてNetworkManagerが自動接続からの接続をブロックしないようにする最も簡単な方法は、block_no_secretsをTRUEに設定しないことです（FALSEに設定するか、最初のifステートメントを完全に削除します）。

0
rubix_addict