Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

how to auto-unlock gnome-keyring on login

Graphical Environments, Managers, Multimedia & Desktop questions.
Post Reply
Message
Author
User avatar
layr
Posts: 86
Joined: 2011-10-11 15:07

how to auto-unlock gnome-keyring on login

#1 Post by layr »

SOLVED, see below

Hi all,
I'm running debian testing without a login manager, i3 as window manager. gnome-keyring & libpam-gnome-keyring packages are installed. There's Login keyring, set as default; password is the same as my user login password: https://i.imgur.com/IPSavEc.jpg
Keyring file is at ~/.local/share/keyrings/login.keyring, file header/start is:

Code: Select all

[keyring]
display-name=Login
ctime=0
mtime=1614101854
lock-on-idle=false
lock-after=false
i3 is started from ~/.xinitrc:

Code: Select all

exec dbus-run-session i3
i3 itself executes script setting up environment. From that script we start polkit:

Code: Select all

dbus-update-activation-environment --systemd --all
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
Added following 2 lines to /etc/pam.d/login:

Code: Select all

auth       optional     pam_gnome_keyring.so
session    optional     pam_gnome_keyring.so auto_start
Now, first thing I don't get is which component is supposed to start the keyring process, and which process actually does it. Does it even matter from automatic unlocking point of view?

In my system it was started by systemd (/etc/systemd/user/graphical-session-pre.target.wants/gnome-keyring-daemon.service), so I disabled said service:

Code: Select all

systemctl --user mask gnome-keyring-daemon
Then there's /usr/share/dbus-1/services/org.gnome.keyring.service which I removed. Even if I comment out the added auth & session lines from /etc/pam.d/login, the keyring process is still started at boot:

Code: Select all

ps -ef | grep keyring
layr        3064       1  0 00:36 tty1     00:00:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
So now I'm in a position where an unknown force is starting the gnome-keyring-daemon and login keyring is still not automatically unlocked at startup.
How to debug this? Maybe someone running debian testing could share their approach?

/var/log/auth.log at the time of bootup & login, with those 2 lines commented out in pam.d/login. System boot was around minute 26, login around 28, and typed in keyring password around minute 29.

/var/log/auth.log at the time of bootup & login, with those 2 lines enabled in pam.d/login. System boot was around minute 58, login around 59, no prompt for keyring password. Note there's a line ("gkr-pam: gnome-keyring-daemon started properly and unlocked keyring") implying all's good, but no keyrings are listed by seahorse in this case: https://i.imgur.com/5DxQMSk.jpg

Just for transparency, here's my stackexchange tread, will keep both this thread and stackexchange updated.
Last edited by layr on 2022-07-11 11:19, edited 1 time in total.

jmgibson1981
Posts: 294
Joined: 2015-06-07 14:38
Has thanked: 11 times
Been thanked: 32 times

Re: how to auto-unlock gnome-keyring on login

#2 Post by jmgibson1981 »

I'll admit I don't know how to fix the issue. I know how to bypass it though. There may be a terminal way but just change the keyring password to nothing. Solved. I do it by installing Seahorse, setting it to no password then remove seahorse (unless want to keep it). At that point the keyring always unlocks. Not great for any kind of security or course.

User avatar
layr
Posts: 86
Joined: 2011-10-11 15:07

Re: how to auto-unlock gnome-keyring on login

#3 Post by layr »

jmgibson1981 wrote: 2022-06-30 15:15 just change the keyring password to nothing. Solved.
Ye I understand it's likely just fine for a personal computer that has encrypted hard drive, but this sorta workaround makes me too uneasy.

jmgibson1981
Posts: 294
Joined: 2015-06-07 14:38
Has thanked: 11 times
Been thanked: 32 times

Re: how to auto-unlock gnome-keyring on login

#4 Post by jmgibson1981 »

Either way the result is what you want though. So it seems like you've already made the decision on the security aspect. Now it's just a matter of implementing it?

User avatar
layr
Posts: 86
Joined: 2011-10-11 15:07

Re: how to auto-unlock gnome-keyring on login

#5 Post by layr »

Think I got it sorted. Don't have deep understanding of what's going on, but it has to do with dbus.
Problem is the way i3 was started from .xinitrc:

Code: Select all

exec dbus-run-session i3
I'm guessing it causes keyring-daemon to be tied to different dbus session than i3 (and, by extension, most everything else in user space).
To overcome this, I'm now launching i3 from ~/.xsession via systemd instead; note I've deleted ~/.xinitrc altogether.

Code: Select all

$ cat ~/.xsession
systemctl --user import-environment
systemctl --user daemon-reload

# note we add the 'wait' flag, which disallows immediate exit, which in turn would stop X session right after it.
exec systemctl --user start --wait xsession.target
startx is started with no arguments (exec startx)

Relevant systemd units:

Code: Select all

$ tree -a ~/.config/systemd/user/
/home/layr/.config/systemd/user/
├── i3wm.service
├── xsession.target
└── xsession.target.requires
    └── i3wm.service -> /home/layr/.config/systemd/user/i3wm.service
    
$ cat ~/.config/systemd/user/i3wm.service 
[Unit]
Description=i3 Window Manager
PartOf=graphical-session.target

[Service]
ExecStart=/usr/bin/i3
ExecStopPost=/usr/bin/systemctl --user stop graphical-session.target
Restart=on-failure

[Install]
RequiredBy=xsession.target

$ cat ~/.config/systemd/user/xsession.target
[Unit]
Description=X session managed by systemd
BindsTo=graphical-session.target
Encrypted keyring now gets unlocked by PAM on login as expected.
Also ignore all the things I tried described in the initial post, besides those two lines in /etc/pam.d/login - those are needed.

Courtesy of this blog.

Post Reply