Currently, I’m using KeePass as passwords, RSA-keys, and as the Freedesktop SecretService, see the KeePass: an MFA TOTP codes, a browser’s passwords, SSH keys passwords storage configuration and Secret Service integration post.
The first issue I faced with during such a setup is the fact that KeePass’ database is synced between my computers (it’s database just stored in a Dropbox folder), and KeePass rewrites some passwords, for example – Chromium creates its own key named “Chromium Safe Storage” for its local SQLite database encryption, and it must be different on each PC, but as the database is synced – I got an issue here.
The second inconvenience is that KeePass is started with a locked database, and applications can not start using it until I’ll not unlock it.
This can be automated for example by using the -pw option (see KeePass options), or by using a GPG key, but in this way I’m losing the whole data encryption idea as all access credentials will be stored on the same filesystem in a plaintext.
Thus – let try to use gnome-keyring for local applications as a SecretService, and leave everything other for the KeePass.
Contents
GNOME Keyring install
Check the D-Bus org.freedesktop.secrets service now:
[simterm]
$ ps aux |grep $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets) setevoy 1534 0.0 0.6 705436 102524 tty1 SLl Jan09 0:03 keepassxc
[/simterm]
Disable SecretService support in the KeePass, install gnome-keyring:
[simterm]
$ sudo pacman -S gnome-keyring
[/simterm]
Check the SecretService again:
[simterm]
$ ps aux |grep $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets) setevoy 829496 0.0 0.0 236292 8528 ? SLl 13:19 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
[/simterm]
Started, working, options – --start --foreground --components=secrets – correct, all good here.
GNOME Keyring unlock on Log In
Now, need to add storage decryption during login to the Operating system, see the Arch Wiki and GNOME Manual documentation.
Check libs:
[simterm]
$ ll /usr/lib/security/ | grep gnome -rwxr-xr-x 1 root root 46768 Oct 29 11:38 pam_gnome_keyring.so
[/simterm]
Edit /etc/pam.d/login, add to the auth and session the following strings:
... auth optional pam_gnome_keyring.so ... session optional pam_gnome_keyring.so auto_start ...
To update keyring’s password during changing a user’s password in the system – add the following line to the /etc/pam.d/passwd:
... password optional pam_gnome_keyring.so
The documentation says it’s necessary to add the eval $(/usr/bin/gnome-keyring-daemon --start --components=secrets) execution to the ~/.xinitrc (or, for example, ~/.config/openbox/environment), but in my case, everything is already working (Arch Linux + Openbox DE with manual X-server start via startx).
Reboot the PC and check D-Bus again:
[simterm]
$ ps aux |grep $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets) setevoy 1338 0.0 0.0 236376 6932 ? Sl 14:35 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
[/simterm]
gnome-keyring processes:
[simterm]
$ ps aux | grep gnome setevoy 1351 0.1 0.0 236288 6776 ? Sl 16:32 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login setevoy 1874 0.0 0.0 235988 7244 ? Sl 16:33 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
[/simterm]
The Login and Default keyrings
After installation, we just checked the service and it looked like:
[simterm]
$ ps aux |grep $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets) setevoy 829496 0.0 0.0 236292 8528 ? SLl 13:19 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
[/simterm]
But on my home laptop “something went wrong” and the gnome-keyring-daemon service was started with the --daemonize --login only, without --components=secrets:
[simterm]
$ ps aux |grep $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets) setevoy 666 0.0 0.0 380756 7280 ? Sl 21:19 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
[/simterm]
And in the Seahorse (see the Seahorse — GUI for gnome-keyring part below) I had an empty Login keyring, and Default – wich was even impossible to unlock:
Check keyrings files:
[simterm]
$ ll .local/share/keyrings/. total 16 -rw------- 1 setevoy setevoy 2689 Dec 8 09:38 Default_keyring.keyring -rw-r--r-- 1 setevoy setevoy 15 Dec 6 08:51 default
[/simterm]
Remove (moved to a Backups dir actually) the Default_keyring.keyring and default files, re-login – and it’s working now.
Seahorse – GUI for the gnome-keyring
Install the Seahorse:
[simterm]
$ sudo pacman -S seahorse
[/simterm]
Run a browser, for example, Brave, and check the Login keyring (must be created by the gnome-keyring after the first login to the system):
The Brave Safe Storage record appeared, thus – Brave is using gnome-keyring, SecretService works, all good.
Database files:
[simterm]
$ ll .local/share/keyrings/ total 8 -rw------- 1 setevoy setevoy 2480 Jan 10 14:38 login.keyring -rw------- 1 setevoy setevoy 207 Jan 10 13:41 user.keystore
[/simterm]
No such secret collection at path: /
Sometimes during creating a new keyring Seahorse may return an error with the “No such secret collection at path: /” message:
The solution is to update environment variables for the D-Bus:
[simterm]
$ source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh
[/simterm]
Done.
