envoy
envoy copied to clipboard
vodik
Strange behavior using pam_envoy without same password in keys
Well, first things first: the #37 was fixed (at least for me) in the last commits... not sure which one, but it works perfectly right now! Thank you :)
But I would like to note that there's a strange behavior when the keys and the user password aren't the same:
When trying to use gpg after I authenticated with LightDM, it will give me an pinentry (in this case pinentry-gtk-2) asking me for the passphrase... okay, everything good until here. In the same terminal, if I try something that will use the gpg-agent as ssh-agent (for example git push), it will simply give me this:
Agent admitted failure to sign using the key.
Permission denied (publickey).
... without even asking me anything!
At the same time, if I just authenticate through an tty, the behaviors will be switched: The gpg will give me the following (yes, always twice):
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled
...again, without asking me anything first. And the ssh command (again, git push) will give me the pinentry (now pinentry-curses) correctly!
AAAAAAND (don't know if I should fill another issue for this one, if I should just tell me and I'll do it) if I authenticate on both LightDM and another tty at the same time... the chaos reigns. When I use anything in the terminal at my desktop, the pinentry will show on the tty as pinentry-curses, and if I try the same on the tty... it appears nowhere!
I would imagine that envoy-exec is here to help in the last situation by setting where the pinentry will appear... but unfortunately it just gives me the following on envoy-exec git push:
[1] 15029 segmentation fault (core dumped) envoy-exec git push
If my account password and gpg key are the same, everything said works fine... but the envoy-exec git push still crashes.
Okay, this sounds like a legitimate problem that I'll have to (unfortunately) reproduce to debug. Yay! I'll hopefully setup a VM for this tonight. Sounds like it'll be a fun one to track down.
What would help is if you did a debug build of envoy and see if you can get me the backtrace of that segfault. Maybe that's enough to make the bug obvious.
Hmm okay... sorry for the silly question, but I believe I have to do it: how to make a debug build? I'm not used to C programming, and looking at the Makefile didn't help me :(
Would you still have the broken build of envoy kicking around? Specifically the version? gdb is telling me the segfault is on a weird line of code, I'm not sure if some of the refactoring work I've done is now getting in the way.
I'm speaking at a conference next week (which is also why its taken me so long to get around to this) but I want to tackle this and focus some serious effort in whipping this project back into shape.
Alright, lets see if I can still reproduce it again now that I'm home.
@dan-silva might be worth trying again on a recent build because I've killed some defects found by Coverity.
Okay, I reinstalled envoy but it still happens in the same way. I tested with v14 from Archlinux official binaries and the same for the AUR package (it's registered as v12.1, but it will get the commit anyway).
Okay, I'm just going to setup a VM and figure this out there. Let me get this straight:
- Archlinux with LightDM
- You unlock your keyring with pam (key password same as user login)
- You get lots of weirdness with pinentry / envoy-exec segfaults.
Missing any steps?
Just to make sure, here it is my /etc/pam.d/lightdm:
#%PAM-1.0
auth include system-login
-auth optional pam_gnome_keyring.so
auth optional pam_envoy.so
account include system-login
password include system-login
session include system-login
session optional pam_envoy.so gpg-agent
-session optional pam_gnome_keyring.so auto_start
... and my /etc/pam.d/login:
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
auth optional pam_envoy.so
account include system-local-login
session include system-local-login
session optional pam_envoy.so gpg-agent
And that's it, I believe there's nothing else important on my setup that could mess with it :)
Cool, thanks. I'll see what I can reproduce tonight. Sorry, I've been tied up with other priorities.
No problem, feel free to ask me anything if its necessary... and if you can't reproduce the issue, we can try a remote session to debug on my machine :)