cruegge / pam-gnupg

Unlock GnuPG keys on login
GNU General Public License v3.0
269 stars 12 forks source link

Is it possible to unlock keys without opening a new session (custom code) #38

Closed user18130814200115-2 closed 2 years ago

user18130814200115-2 commented 2 years ago

On my system (voidlinux), I have agetty1 set to autologin, meaning pam does not receive the password and pam-gnupg can't unlock my keys. Immediately after login however, I run swaylock which does give the password to pam-gnupg. Since swaylock does not open a new session however, the keys are not unlocked. My question therefore is, is is possible to modify the code to allow the starting of gpg-agent to occur after authrather than session? If this is possible I will add this to my own fork as I understand that this is not wanted default behaviour.

cruegge commented 2 years ago

You're actually asking two different things here: starting the agent and unlocking the keys. Starting is not supported in auth, but unlocking should be no problem if you do not use the store-only option. The easiest way to make your case work is probably to start the agent manually on login in your init scripts. Otherwise, it is in principle possible to modify the code to start the agent, but the side effect is that every entered password will be sent to the agent, effectively making it possible for other users to lock your keyring by entering a wrong password for you. It might be possible to configure the pam stack to not run the module at all if a previous authentication step failed, but I don't know from the top of my head how to do that.

cruegge commented 2 years ago

Wait, I don't seem to know my own code here: it is possible to autostart in auth. I think the reason for not supporting it was that the environment might not be set up properly before opening a session, but in your case swaylock runs in a useable environment, so it should be fine. I'd still prefer the route via the init scripts, but if you disagree, you can try simply changing the third function call arg this line to true.

user18130814200115-2 commented 2 years ago

Alright thanks! I ended up taking your recommended approach of starting the gpg agent in my init script just before swaylock.

Interestingly, I noticed that the gpg_agent did get autostarted though seemingly at the end of the process as my log states:

pam_gnupg(swaylock:auth): stored passphrase
pam_gnupg_helper: child terminated with exit code 1
pam_gnupg(swaylock:setcred): helper terminated with exit code 1
pam_gnupg(swaylock:setcred): presetting failed, retaining passphrase

After this, the gpg agent is running and if I launch swaylock again, the keys are unlocked. Is this a bug? Because auth should not be starting the agent like this right? FYI my swaylock pam config looks like:

auth include login
auth optional pam_gnupg.so debug

With nothing special in login

Anyways, thanks for your help, if this is a bug it may be good to open a new issue about it because my issue was resolved :).

cruegge commented 2 years ago

That should definitely not happen. On a systemd-based distro, I'd assume that the agent was started by socket activation. I'm not overly familiar with Void's runit init system; does something comparable exist there? Or do you run any additional pass-commands after unlocking, which also might start the agent?

user18130814200115-2 commented 2 years ago

You are right, I was using pass to test if the keys were unlocked, this was what was starting the agent.

Thanks again!