Gnome-keyring not working

mbod · October 26, 2020, 8:25am

This issue is not only about gnome-keyring not working. I am probably facing a bigger problem with my user environment. The keyring just made it obvious. Thats why I am posting this here in the gnome section.

I moved from Manjaro to EndeavourOS with a clean system installation but I kept my home directory. I am using xfce and sometimes gnome. I realized in xfce that evolution takes a long time to query my imap server and then is asking me for a password. Which it never did before. gnome-keyring-daemon is running but not communicating with evolution. Also seahorse is not showing the password section. It only shows gpg and ssh keys. And this is also true when trying this in gnome. On my laptop everything is working fine with my old home directory.

So I figured something must be wrong with the environment. I started to compare laptop and PC.

Here are a couple of findings using xfce+lightdm:

On the PC several gnome processes have PPID=1:

3# ps -ef | grep gnome
matthias    4619       1  0 08:51 ?        00:00:00 /usr/lib/gnome-shell-calendar-server
matthias   11238       1  0 08:59 ?        00:00:00 /usr/lib/gnome-shell-calendar-server
matthias   19029       1  0 09:10 ?        00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
matthias   19087       1  0 09:10 ?        00:00:00 /usr/lib/at-spi2-registryd --use-gnome-session
matthias   19246   19032  0 09:10 ?        00:00:00 /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
matthias   19910   19819  0 09:11 pts/0    00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox gnome

On the laptop this is not the case
/usr/lib/at-spi2-registryd for exmaple is owned by /usr/lib/systemd/systemd --user

That brings me to the next odd thing. On the laptop systemd --user has a long list of running services:

# systemctl status --user
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Sun 2020-10-25 21:33:32 CET; 11h ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─gvfs-goa-volume-monitor.service 
           │ └─1407 /usr/lib/gvfs-goa-volume-monitor
           ├─evolution-calendar-factory.service 
           │ └─1448 /usr/lib/evolution-calendar-factory
           ├─pulseaudio.service 
           │ ├─2213 /usr/bin/pulseaudio --daemonize=no --log-target=journal
           │ └─2282 /usr/lib/pulse/gsettings-helper
           ├─gvfs-daemon.service 
           │ ├─1120 /usr/lib/gvfsd
           │ ├─1125 /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f
           │ └─1439 /usr/lib/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0
           ├─evolution-source-registry.service 
           │ └─1395 /usr/lib/evolution-source-registry
           ├─gvfs-udisks2-volume-monitor.service 
           │ └─1331 /usr/lib/gvfs-udisks2-volume-monitor
           ├─init.scope 
           │ ├─1088 /usr/lib/systemd/systemd --user
           │ └─1089 (sd-pam)
           ├─gpg-agent.service 
           │ └─2631 /usr/bin/gpg-agent --supervised
           ├─gvfs-gphoto2-volume-monitor.service 
           │ └─1400 /usr/lib/gvfs-gphoto2-volume-monitor
           ├─at-spi-dbus-bus.service 
           │ ├─1133 /usr/lib/at-spi-bus-launcher
           │ ├─1139 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
           │ └─2197 /usr/lib/at-spi2-registryd --use-gnome-session
           ├─gvfs-metadata.service 
           │ └─1444 /usr/lib/gvfsd-metadata
           ├─dbus.service 
           │ ├─1108 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │ ├─1141 /usr/lib/xfce4/xfconf/xfconfd
           │ ├─1411 /usr/lib/goa-daemon
           │ ├─1425 /usr/lib/goa-identity-service
           │ ├─1463 /usr/lib/dconf-service
           │ └─2199 /usr/bin/xfce4-screensaver --no-daemon
           ├─evolution-addressbook-factory.service 
           │ └─1470 /usr/lib/evolution-addressbook-factory
           ├─gvfs-mtp-volume-monitor.service 
           │ └─1396 /usr/lib/gvfs-mtp-volume-monitor
           └─gvfs-afc-volume-monitor.service 
             └─1430 /usr/lib/gvfs-afc-volume-monitor

While on the PC this list is really short:

# systemctl status --user
* rakete
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2020-10-26 08:51:49 CET; 25min ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           |-pulseaudio.service 
           | |-19109 /usr/bin/pulseaudio --daemonize=no --log-target=journal
           | `-19281 /usr/lib/pulse/gsettings-helper
           |-init.scope 
           | |-4482 /usr/lib/systemd/systemd --user
           | `-4509 (sd-pam)
           |-gpg-agent.service 
           | `-5744 /usr/bin/gpg-agent --supervised
           |-pipewire.service 
           | |-5524 /usr/bin/pipewire
           | `-5526 /usr/bin/pipewire-media-session
           `-dbus.service 
             `-4586 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

seahorse is not showing the password keyring on the PC but just keys and certificates:

On the laptop it shows me the login keyring:
laptop

So something is odd on my PC. And it is also odd when I login to gnome. I did a reset of all gnome settings with

dconf reset -f /org/gnome/

and Reset to Defaults in the gnome tweak tool. But that didnt help.

Any idea what is going on here?

EDIT:
I tried with the original home directory which was created during EndeavourOS installation. Same story. So this issue seems to be independent of the home directory.

mbod · October 27, 2020, 6:33am

I have some more insight but no solution.

I disabled the pam_gnome_keyring.so modul in /etc/pam.d/lightdm

1# cat /etc/pam.d/lightdm
#%PAM-1.0
auth        include     system-login
#auth       optional    pam_gnome_keyring.so
account     include     system-login
password    include     system-login
session     include     system-login
#session    optional    pam_gnome_keyring.so auto_start

and I added this to ~/.xinitrc instead:

# https://wiki.archlinux.org/index.php/GNOME/Keyring#PAM%20method
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK

Doing this has some positive effect. (1) seahorse is now showing the Passwords section and (2) evolution is now immediately asking for a password for the keyring and is able to open it. And the keyring stays open.

lightdm is supposed to unlock the gnome-keyring for the user but it isnt doing that. Any idea?

csteinforth · October 27, 2020, 7:17am

Is your ‘login’ keyring missing somehow?

mbod · October 27, 2020, 10:15am

Yes of course. Otherwise I assume the trick with .xinitrc would not work either.

joekamprad · October 27, 2020, 12:36pm

do you simple add old /home to be mounted as /home for new install? creating a user with the same username then before? i would bet it will bring issue with it. can be that it does not create a new keyring for you and using the old one fails, or some settings do not fit with it.
I would ever create a new user with a new home and then copy needed configs over one by one.
you can do now also by removing user leaving home and create a new one (rename old home if you want to keep username) then login with new user and copy your files over from old to new home folder.

mbod · October 27, 2020, 12:43pm

Let me quote myself:

joekamprad · October 27, 2020, 12:55pm

sry i over-read this one.
what say:
test -f ~/.local/share/keyrings/login.keyring && echo "Have 'login' keyring"

joekamprad · October 27, 2020, 1:09pm

you can simple generate a new one:
2020-10-27_14-08
click the plus-sign and choose password

mbod · October 27, 2020, 2:19pm

Yes. I did all this. I have an ew keyring and it works - but just not out of lightdm.
I did some more testing.

The default lightdm pam config looks like this:

#cat /etc/pam.d/lightdm
#%PAM-1.0
auth        include     system-login
auth       optional    pam_gnome_keyring.so
account     include     system-login
password    include     system-login
session     include     system-login
session    optional    pam_gnome_keyring.so auto_start

When I leave it like that, seahorse does not see the login keyring. Like shown in the first screenshot in my first post.

But when I take out the last line: session optional pam_gnome_keyring.so auto_start

Then seahorse sees the login keyring, like in the second screensho of my first post. And I can unlock the keyring with seahorse. Then I see the evolution keys in the keyring and evolution is starting without delay and without asking for a password again.

So this clearly an issue with lightdm and gnome-keyring-daemon. Weird.

joekamprad · October 27, 2020, 4:06pm

GNOME does not support lightdm, so they force you to use GDM, may something changed on GNOME and lightdm developers do not change that.

mbod · October 27, 2020, 5:36pm

I checked with gdm+gnome as well. Same problem.

joekamprad · October 27, 2020, 6:44pm

same problem with GDM?
not having loginkey?
The initial install of EndeavourOS was with xfce only? or do you install XFCE and GNOME together ?

mbod · October 27, 2020, 7:47pm

I installed gnome afterwards with packages gnome+gnome-extra

mbod · October 29, 2020, 7:28am

I still do not know what is wrong with the setup on my PC. On my laptop everything works fine. I have tested anything I could think of.

Any ways, I have a workaround now and I will leave it as such for the time being:

I have removed all pam_gnome_keyring.so from /etc/pam.d/lightdm and set an empty password for my keyring. This way evolution is working just fine.

mbod · October 30, 2020, 7:32am

I found the root cause of the issue! Yipiiieeh!

I had added

export $(dbus-launch)

to /etc/profile. If I take that out lightdm with keyring works just fine. Interesting.

Why did I have that in /etc/profile?

Because I use terminator as my terminal app and I have an alias to start a root shell:

alias rterm='sudo -iHb terminator --geometry 1276x1369-0+41 2>/dev/null'

Without the dbus-launch in /etc/profile this fails because terminator can not open the DISPLAY:

16# Traceback (most recent call last):
  File "/usr/bin/terminator", line 87, in <module>
    dbus_service = ipc.DBusService()
  File "/usr/lib/python3.8/site-packages/terminatorlib/ipc.py", line 42, in __init__
    self.prepare_attributes()
  File "/usr/lib/python3.8/site-packages/terminatorlib/ipc.py", line 49, in prepare_attributes
    bus = dbus.SessionBus()
  File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 212, in __new__
    return Bus.__new__(cls, Bus.TYPE_SESSION, private=private,
  File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 102, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python3.8/site-packages/dbus/bus.py", line 124, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/terminator", line 108, in <module>
    ipc.new_window_cmdline(optionslist)
  File "/usr/lib/python3.8/site-packages/terminatorlib/ipc.py", line 192, in _exec
    bus = dbus.SessionBus()
  File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 212, in __new__
    return Bus.__new__(cls, Bus.TYPE_SESSION, private=private,
  File "/usr/lib/python3.8/site-packages/dbus/_dbus.py", line 102, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python3.8/site-packages/dbus/bus.py", line 124, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead

Now I am looking for a new solution for this terminator problem. Any ideas?

mbod · October 30, 2020, 7:47am

I answer to myself here. I have the solution for the terminator issue. I simply add the

export $(dbus-launch)

to the root users ~/.zprofile (yes, I am using zsh). That was it.

I mark this thread as solved.

joekamprad · November 10, 2020, 1:57pm

if this is needed only for one application, you should set this per application and not systemwide

mbod · November 10, 2020, 2:23pm

I have set it for user root in /root//.zprofile. I have not experienced any issue so far. Do you see any issue with that?

Or do you have any other solution for the DISPLAY issue when starting terminator with sudo? sudo -iHb terminator

mbod · November 11, 2020, 7:07am

@joekamprad
I found a solution now which is more according to your recommendation:

I can simply add the dbus-launch command to the alias I am using:

alias rterm='sudo -iHb dbus-launch terminator"

That is doing the trick. No need to add anything to /root/.zprofile.

Echoa · November 11, 2020, 7:50am

This is 90% true, technically you can use lightdm but you wont have the ability to lock your screen which is really annoying. If you want the system to work 100% as expected yeah you kinda need GDM

The reason is the tied the locking directly to GDM afaik and a few other things related in that regard and lightdm cant be GDM so meh (tried real hard to make it work at one point because i like lightdm)