結論
gnome-keyring や libsecret を入れます。/etc/pam.d/<使用しているdisplay manager (もしくはlogin manager)>で以下を有効にします。無いならば追記します。ly に pam_keyinit の部分はありませんでした。
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
session optional pam_keyinit.so force revoke
環境
- Linux Distribution: Arch Linux
- Display Manager: Ly
- Window Manager: CwC
- VSCode: visual-studio-code-bin 1.105.1-1
経緯
Arch Linux で AUR 経由で VSCode を入れた。
設定が面倒で sign in して設定を同期させようと思ったが、以下の警告ポップアップが出てきた。
You're running in a GNOME environment but the OS keyring is not available for encryption. Ensure you have gnome-keyring or another libsecret compatible implementation installed and running.
一旦 microsoft 公式の指示 に従うが、 gnome-keyring を入れてだめだった。
Arch Linux の wiki で GNOME Keyring の記事 を見ると次のように。
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of /etc/pam.d/login as mentioned below.
When using console-based login, edit /etc/pam.d/login:
Add auth optional pam_gnome_keyring.so at the end of the auth section and session optional pam_gnome_keyring.so auto_start at the end of the session section.
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
auth optional pam_gnome_keyring.so
account include system-local-login
session include system-local-login
session optional pam_gnome_keyring.so auto_start
If using the greetd login manager, the file that needs to be modified is /etc/pam.d/greetd, instead of /etc/pam.d/login.
/etc/pam.d/ly に書いて再起動して反映してみても sign in できない。
解決策を調べるのが面倒になったので chat-gpt に聞けばとりあえず gnome-keyring を入れろと。
言われて知った下記コマンドで gnome-keyring-daemon が動いているか調べるが、普通に元気に動いている。
ps aux | grep gnome-keyring-daemon
これに対し、 chat-gpt は「GNOME_KEYRING_CONTROL や XDG_RUNTIME_DIR がアプリ実行時に設定されていないと接続不可になる」と言う。
確かに XDG_RUNTIME_DIR は設定されているものの、 GNOME_KEYRING_CONTROL は設定されていなかった。
以下を試してアプリを立ち上げろと言うが、結果 sign in はできなかった。
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK
export GNOME_KEYRING_CONTROL
「アプリが keyring の D-Bus サービス (org.freedesktop.secrets) にアクセスできていない」説を提示してきた。下記コマンドで調べると普通に org.freedesktop.secrets は出てきた。アクセスできている。
busctl --user list | grep secrets
残る可能性として「アプリの実行環境が D-Bus セッションに接続していない」を提示してきた。 echo $DBUS_SESSION_BUS_ADDRESS は空じゃなくて正常な状態だったのでこれでもない。
そうすると libsecret がリンクされていない説を挙げてきた。流石にないだろうが、一応調べようとする。すると secret-tool なるものの話が出てきた。これを調べると、 secret-tool が動かないみたいな記事 が出てきた。
この記事の最後の方にこんなコメントがあった。
Now I have found that on Ubuntu pam configuration contains:
# Create a new session keyring.
session optional pam_keyinit.so force revoke
Arch doesn't contain or doesn't use this pam_keyinit module, I think this can be a reason why on Ubuntu gh auth login can use keyring and on Arch can't.
From man 8 pam_keyinit:
pam_keyinit - Kernel session keyring initialiser module
The pam_keyinit PAM module ensures that the invoking process has a session keyring other than the user default session keyring.
What means it's the Kernel keyring that is attached to every process or thread. I don't know if libsecret can use this Kernel keyring if Gnome keyring isn't available but it looks like it can be it. I didn't find any other systemd units or anything else that can provide keyring, only this pam_keyinit module. But I only spent a few minutes on it, took me much longer to write this reply. 🙂
I tried to enable pam_keyinit on Arch and it didn't help, secret-tool store --label='test1' a1 v1 still prints the same error. I'm confused. 😁 It could still have something to do with the dbus.
あれ？これでは？となった。早速 /etc/pam.d/ly に追記する。
# Create a new session keyring.
session optional pam_keyinit.so force revoke
再起動すると…… これだった！！！ ありがとう。コメントを書いてくれた方！
