Hello, I’m using a fresh install of Ubuntu 22.04 where I installed KDE on top. For login I use SDDM. gnome-keyring starts and works fine, I have Seahorse installed and everything is OK, but I do have to input the password every time I launch a gnome-keyring dependant app. This is very annoying, so I tried two things:
1 - Create and blank-password gnome-keyring: it works, but the keyring is removed after a few days/reboots, no idea why.
2 - Try to unlock at boot: no idea how, I would try removing the “-” before the gnome-keyring lines on SDDM, but this comment scares me: “# gnome_keyring breaks QProcess”
So, what can I do? How could I prevent the blank-password gnome-keyring from deleting, or how could I unlock my default keyring at boot without entering the password?
Thanks in advance.
Sorry, I don’t know the correct answer to your question (I had a similar problem once, years ago, but I forget how I solved it).
However, seeing as this is a fresh installation, and you want KDE, why don’t you just install Kubuntu instead of KDE on top of Ubuntu? That way, everything will be installed together as designed, and should work out the box, so to speak.
It’s a company PC so I can’t do that, also, if the apps I’m trying to use are designed to forcibly
use gnome-keyring… wouldn’t be the same?
from my experience, for it to be permanent, you need to move away from default keyring and create additional one (and set it to blank password)
don’t remember where I saw that tip, but it works for me
That could work, but how do I tell the apps that use gnome-keyring to use the non-default one? They always fall back to the default keyring.
Sorry, I meant: create new keyring and set is as default
Yes, a new default with no password keyring works, but as I say on my first post, for some reason it dissapears after a few days/reboots.
If it’s a company machine they may have it set to enforce requirement of a password. Could be a simple shell script that removes the user created keyring on a system user you cant access. Just in case it gets lost they don’t have to worry about unfettered access.
Just a theory. Businesses can lock down anything they want if they have a competent admin around.
I don’t think that’s the case. In any case, we are not focusing on my question: how can I automatically unlock the keyring at boot?
well, you should focus on why your custom keyring disappears without your intention then, because as far as I know setting blank password is the correct way to have the keyring unlocked automatically. I have this setup and it works, but I only use clean gnome… (https://unix.stackexchange.com/questions/771331/prevent-gnome-keyring-password-being-reset-after-update)
1 Like
I’ll try to investigate it.
I actually have no clue on how to search for the reason of the deletions. Should I check some specific log or something?
EDIT
BTW, I always have this process running when I boot the PC:
/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
I suspect this process may be deleting the keyrings for some reason, at least to discard it, I would like to boot my PC without any keyring daemon.
But how is it even starting? I have disabled the gnome-keyring autostart desktop files on /etc/xdg/autostart, and I have nothing on sddm.conf in PAM files (I use SDDM as login screen/service).
I guess some other process must be launching it, but how could I find out?
EDIT 2
According to the pstree command, this is the process that starts it:
systemd (sd-pam)
No idea how though.
You need to understand that the sd-pam process is a helper process for managing PAM sessions for a user. It is automatically spawned by systemd when a user logs in and is responsible for opening and closing PAM sessions. You do not manually start the sd-pam process; it is managed by systemd as part of the login process.
need to find a real reason, but I could’nt tell you how on a mixed system. Sorry.
I love a challenge, so what I did is edit /etc/pam.d/login
And I added this at the bottom:
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
This configuration will start the GNOME Keyring Daemon and unlock the login keyring with the user’s login password upon login.
Please give that a try.
So you’re saying that, beacuse I cleanly installed KDE desktop over a clean Ubuntu install, something is broken? How nice…
People often criticize Windows and Mac over Ubuntu, but because of things like this Linux is not my daily driver… there’s always a catch.
And no, I don’t think a clean Kubuntu install would fix anything, my impression is that KDE and gnome-keyring are not well intregrated and, the moment I tried to use a gnome-keyring dependant app on a clean Kubuntu install, the same would happen.
I’m gonna try your suggestion and post back, but let me foreshadow what will happen: I will end up with two gnome-keyring-daemon processes, the one I already have and other with the --login option. The keyring will probably not be unlocked at boot, and, if left without a pass, it will eventually dissparear, as of now.
BTW, I also love a challenge too. I just saw this on system logs:
gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
EDIT
Never mind, it’s an old line… here’s the relevant lines of my last boot:
mar 04 20:50:55 kernel: Initialise system trusted keyrings
mar 04 20:50:55 kernel: integrity: Machine keyring initialized
mar 04 20:51:21 gnome-keyring-daemon[4069]: couldn't access control socket: /run/user/1000/keyring/control: No existe el archivo o el directorio
mar 04 20:51:21 gnome-keyring-d[4069]: couldn't access control socket: /run/user/1000/keyring/control: No existe el archivo o el directorio
mar 04 20:51:21 gnome-keyring-daemon[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/passdefault.keyring
mar 04 20:51:21 gnome-keyring-d[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/passdefault.keyring
mar 04 20:51:21 gnome-keyring-d[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/def.keyring
mar 04 20:51:21 gnome-keyring-daemon[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/def.keyring
mar 04 20:51:21 gnome-keyring-daemon[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/login.keyring
mar 04 20:51:21 gnome-keyring-d[4069]: keyring was in an invalid or unrecognized format: /home/pmsobrado/.local/share/keyrings/login.keyring
No clue this time about who is starting it, but, I can see there my old keyring stores that got deleted, apparently they are not recognized for some reason…
Mine is working, important to see if pam_gnome_keyring.so is running:
ls /usr/lib/x86_64-linux-gnu/security/
pam_access.so pam_faildelay.so pam_localuser.so pam_rootok.so pam_time.so
pam_cap.so pam_faillock.so pam_loginuid.so pam_securetty.so pam_timestamp.so
pam_cifscreds.so pam_filter.so pam_mail.so pam_selinux.so pam_tty_audit.so
pam_debug.so pam_ftp.so pam_mkhomedir.so pam_sepermit.so pam_umask.so
pam_deny.so pam_gnome_keyring.so pam_motd.so pam_setquota.so pam_unix.so
pam_echo.so pam_group.so pam_namespace.so pam_shells.so pam_userdb.so
pam_ecryptfs.so pam_issue.so pam_nologin.so pam_stress.so pam_usertype.so
pam_env.so pam_keyinit.so pam_permit.so pam_succeed_if.so pam_warn.so
pam_exec.so pam_limits.so pam_pwhistory.so pam_systemd_loadkey.so pam_wheel.so
pam_extrausers.so pam_listfile.so pam_rhosts.so pam_systemd.so pam_xauth.so
Mine is, now I’ll look in my keyrings for any strays:
ls .local/share/keyrings/
login.keyring user.keystore
I’ll keep an eye on this, I have to get to work. ;(
Yes, I have pam_gnome_keyring.so. In any case, want I want now, at least temporarily, is to disable that foreground daemon process. I think I finally found it here:
/usr/lib/systemd/user/gnome-keyring.service
I guess systemctl --user disable gnome-keyring should disable it on boot, but I’m not so sure.
I’ll try and see what happens.
No dice:
ws:~$ ps -ef | grep keyring
ws+ 3863 3453 0 21:42 ? 00:00:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
ws+ 5455 5371 0 21:42 pts/1 00:00:00 grep --color=auto keyring
ws:~$ systemctl --user status gnome-keyring.service
○ gnome-keyring.service - Start gnome-keyring for the Secrets Service, and PKCS #11
Loaded: loaded (/usr/lib/systemd/user/gnome-keyring.service; disabled; vendor preset: enabled)
Active: inactive (dead)
ws:~$ systemctl --global status gnome-keyring.service
○ gnome-keyring.service - Start gnome-keyring for the Secrets Service, and PKCS #11
Loaded: loaded (/usr/lib/systemd/user/gnome-keyring.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Service is disabled apparently, yet someone is starting the daemon.