pam configs for unlocking keyring on login

[nekopsykose]

with default upstream gnome-keyring, it uses gcr3. gcr3 has /usr/libexec/gcr-prompter, which provides a default dbus-launchable org.gnome.keyring.SystemPrompter (and PrivatePrompter etc) that applications trying to talk to the name will get. gcr4 does not have this anymore.

gnome itself implements this in gnome-shell, so it can still show a prompt. but outside of gnome there is no other implementation of this that i can see, except in phosh (lol). this means it's impossible to actually use keyrings at all without gnome

also unrelatedly, we are missing the default config for it to unlock the login keyring outside of gnome too:

diff --git a/main/linux-pam-base/files/system-login b/main/linux-pam-base/files/system-login
index ef3a8062d..bef0f987e 100644
--- a/main/linux-pam-base/files/system-login
+++ b/main/linux-pam-base/files/system-login
@@ -3,18 +3,21 @@
 auth       required   pam_shells.so
 auth       requisite  pam_nologin.so
 auth       include    system-auth
+-auth      optional   pam_gnome_keyring.so

 account    required   pam_access.so
 account    required   pam_nologin.so
 account    include    system-auth

 password   include    system-auth
+-password  optional   pam_gnome_keyring.so use_authtok

 session    optional   pam_loginuid.so
 session    include    system-auth
-session    optional   pam_motd.so       motd=/etc/motd
-session    optional   pam_mail.so       dir=/var/mail standard quiet
-session    optional   pam_keyinit.so    force revoke
+session    optional   pam_motd.so          motd=/etc/motd
+session    optional   pam_mail.so          dir=/var/mail standard quiet
+session    optional   pam_keyinit.so       force revoke
+-session   optional   pam_gnome_keyring.so auto_start
 -session   optional   pam_turnstile.so
 -session   optional   pam_elogind.so
 session    required   pam_env.so

gdm already loads these via pam, but without gdm this isn't done. these are unrelated to the actual issue (these are just the extra features of unlock-on-login and change-keyring-password-along-with-passwd)

---

the only immediate solution i can think of is to use gcr3 again. unless someone implemented a generic version of this that can be packaged and i can't find it

[nekopsykose]

alternatively- an entire alternative keyring implementation would also "work", since things talk to 'a keyring' (gnome-keyring) and gnome-keyring tries to launch the prompter. but nobody makes those either, the only other keyring impls i'm aware of are the kde one (lol) and keepassxc (double lol), and the latter doesn't even work for some applications..

[nekopsykose]

it's also possible to do something like gnome-keyring-daemon [..] --login --unlock and type in the password on the cli and hit ^D (this also doesn't even work consistently?), in which case the prompter is never needed (to prompt for unlock) - but that is quite awkward obviously

[q66]

gcr3 has been added back and i've rebuilt stuff with it, so this should be at least partially fixed; still need to think about the base PAM stuff though (so i'll keep it open until that has been addressed)

[nekopsykose]

sorry for overloading the issue with two wholly separate things..

[nekopsykose]

https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/163 is a reference since kde needs this fixed too

[q66]

i'm still not really sure about including these in system-login, won't it cause issues for gdm and other things that re-include the keyring bits?

[q66]

it will also mean launching gnome keyring on non-gnome desktops by default if present, which is kind of awkward...

[nekopsykose]

won't it cause issues for gdm and other things that re-include the keyring bits?

i think the second launched one just dies? kinda weird tho

i don't know of any other way to do it when someone wants to set it up manually aside from editing the files