PAM login failure after update to bd2ca31 about fscrypt HOT 16 CLOSED

This may be the bug I'm fixing with #97. It was causing glibc to silently abort() the login process later in the PAM stack, so the login prompt would just appear again. It may have started appearing after 5d71e1d switched Argon2 implementations from C to Go, because that may have started making the Go runtime leave extra threads around.

from fscrypt.

Sure, I'll post the links here when I've reproduced it in a VM 👍

from fscrypt.

@sebadoom Thanks for reporting this! For the life of me I cannot figure out how you're hitting this on bd2ca31 but not on 141265f. It looks like the only stuff that was changed between those versions has nothing to do with the pam modules.

I really want to get a system where this is breaking. You mentioned ArchLinux and GDE, anything else installed relating to login or PAM?

from fscrypt.

Nope, fairly standard ArchLinux installation: GDM + Gnome, all up-to-date, no external repos (all standard), standard PAM (except for fscrypt). If you are willing to wait for a bit, I think I can prepare a VM image with Arch to see if I can repro it there.

from fscrypt.

If you could that would be amazing. I think I'm also going to finally setup ArchLinux myself (it sounds fun).

from fscrypt.

Unfortunately, I did a complete clean Arch install in a VM and I haven't been able to reproduce this. It does happen on my main system though. I did not install revision 141265f first in the VM before installing HEAD, I just went straight to HEAD. I'm guessing there is some sort of incompatibility between the metadata stored in the disk between versions. I did notice the protoc version was bumped, could that be the cause? I will now try to do a full reinstall but first go through the revision that is working on my main system before updating to HEAD and report back.

from fscrypt.

Nope, cannot reproduce this on a VM. I'm out of ideas. There's something definitely odd about my system: I am not hitting #77 but I am hitting this. And in the VM I posted in #77 I am hitting that bug but not this one!

from fscrypt.

@sebadoom Thanks for helping out in looking into this. I checked out the metadata compatibility issue. All metadata for fscrypt are just binary protobufs, so a incompatibility there would be a serious bug.

I did a quick check, and HEAD can read metadata created by v0.2.2 and 141265f, so that's (unfortunately) not it. I have a theory that upgrades while a user is logged in might trigger this in some way. I think hacking on your VM in #77 might be enlightening.

from fscrypt.

I've been trying to trigger this in the VM by performing updates while logged in with the user whose home is encrypted and unlocked by pam_fscrypt.so to no avail. If you want me to run more tests, let me know.

from fscrypt.

I would suggest checking if pam_keyinit.so is called in /etc/pam.d/systemd-user

I put full details in an Ubuntu bug here, but the short version is that without this the session keyring is not linked to the user keyring and thus the key is not used even if it exists in the user keyring.
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754270

Though this is arch you mentioned it being broken on your main system but not a fresh install. So perhaps the PAM config on your main system was different and/or not updated to a newer config style at some point.

If that's not the issue please ignore the noise!

from fscrypt.

I would suggest checking if pam_keyinit.so is called in /etc/pam.d/systemd-user

It should by default an Arch. https://git.archlinux.org/svntogit/packages.git/plain/trunk/systemd-user.pam?h=packages/systemd

from fscrypt.

Though this is arch you mentioned it being broken on your main system but not a fresh install. So perhaps the PAM config on your main system was different and/or not updated to a newer config style at some point.

I did compare the main PAM files from both systems and they matched. There must be some other difference but I haven't been able to find it.

from fscrypt.

Chiming in to say that this affects my Arch system as well. After downgrading, I tried upgrading again with no user logged in and policies locked, it made no difference.

@sebadoom - I noted that your PAM config is different from mine, as I just put pam_fscrypt.so in system-auth. Is there a reason to put stuff in system-login?

from fscrypt.

Using version v0.2.3-8-g3e32282 now and everything seems to be in order.

from fscrypt.

I can confirm revision 3e32282 appears to fix the problem. Great catch @ebiggers.

from fscrypt.

Closing as v0.2.4 contains this fix and will shortly be picked up by Ubuntu/Debian/AUR.

Thanks again @ebiggers and @sebadoom

from fscrypt.