Cant unlock key with i3lock

[theRealCarneiro]

I have managed to make it work with startx but when it wont work in i3lock I have followed the tutorial in the readme but still wont work, I installed pam-gnupg from the aur, also i use the i3lock-colors-git from the aur too

Here's what the pam.d/i3lock looks like

auth include system-auth # For Arch/Gentoo auth optional pam-gnupg.so

The i3lock init script: gpg-connect-agent --no-autostart reloadagent /bye i3lock -B 5

[cruegge]

It should be pam_gnupg.so, with an underscore. I was unfortunately not really consistent with _ vs -, and it's too late to change that now.

[theRealCarneiro]

I changed it to: auth optional pam_gnupg.so and it still wont work with i3lock, it still works when i login tho

[cruegge]

Your setup looks ok so far, it's almost the same as mine. Do you have any unusual gpg setup? Or did you change pam.d/system-auth in some way? Also, does journalctl show any warnings when you unlock?

[theRealCarneiro]

My gpg setup has nothing unusual, it is in .config/gnupg, and yes i changed it on .pam_environment

~/.config/gnupg

max-cache-ttl 60480000
default-cache-ttl 60480000
allow-preset-passphrase

~/.pam_environment

GNUPGHOME DEFAULT=@{HOME}/.config/gnupg

As regarding pam.d/system-auth, i did not change anything that I'm aware of

#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
auth       [success=2 default=ignore]  pam_unix.so          try_first_pass nullok
-auth      [success=1 default=ignore]  pam_systemd_home.so
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so

session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so

jornalctl shows me this when i unlock i3lock:

nov 13 08:09:53 arch systemd[1405]: Started GnuPG cryptographic agent and passphrase cache.
nov 13 08:09:53 arch gpg-agent[38635]: gpg-agent (GnuPG) 2.2.23 starting in supervised mode.
nov 13 08:09:53 arch gpg-agent[38635]: using fd 3 for std socket (/run/user/1000/gnupg/S.gpg-agent)
nov 13 08:09:53 arch gpg-agent[38635]: using fd 4 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra)
nov 13 08:09:53 arch gpg-agent[38635]: using fd 5 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser)
nov 13 08:09:53 arch gpg-agent[38635]: using fd 6 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh)
nov 13 08:09:53 arch gpg-agent[38635]: listening on: std=3 extra=4 browser=5 ssh=6

[cruegge]

It looks like your gpg-agent is restarting, which is odd since your lock script only flushes the password cache but does not terminate the agent. Do you have an idea why that happens? I suspect the issue may be due to the agent (re)start happening after the password has been sent to it.

[theRealCarneiro]

The strange part is that I don't see any gpg-agent.service in systemd, I have no idea why this is happening Edit: I did some tests and the gpg agent is being restarted the moment I confirm my password, and this does not happen if I remove auth optional pam_gnupg.so

[cruegge]

I think this may be due to socket activation: systemd listens on the default socket location (/run/user/1000/gnupg/S.gpg-agent.ssh), but since you changed GNUPGHOME, the socket for your instance is somewhere else. Therefore, systemd starts another instance when pam_gnupg sends the passphrase. I don't understand, however, why pam_gnupg ignores your GNUPGHOME in the first place. All it does is call gpg-connect-agent, which should work, and indeed does so when you log in initially. Maybe somethings wrong with the way pam_gnupg obtains the environment from pam_env.

I can't test anything right now, but I'll hopefully do some digging around later today. Can you maybe make sure that GNUPGHOME is set properly directly before i3lock is started?

[theRealCarneiro]

GNUPGHOME is set on my .zprofile and .profile export GNUPGHOME="$XDG_CONFIG_HOME/gnupg"

i3lock launch script:

#!/bin/sh
GNUPGHOME="$XDG_CONFIG_HOME/gnupg"

gpg-connect-agent --no-autostart reloadagent /bye 
i3lock -B 0.4

and .pam_environment GNUPGHOME DEFAULT=@{HOME}/.config/gnupg

[cruegge]

I just pushed a possible fix. Can you test (i.e. install pam-gnupg-git)? The problem was that pam_env as called from system-auth does not read .pam_environment, so GNUPGHOME was effectively unset by using the pam-provided env. I assume in most setups .pam_environment is only read when opening a session, so I disabled using the pam environment during auth, thereby reusing the existing session env. Not sure if that breaks anyone else's setup unfortunately, but it should work for your case now.

[theRealCarneiro]

It works perfectly now, thank you