Update sys-apps/shadow-4.1.5-r1 came today to one of my machines earlier, which ended up with su yielding "su: Authentication failure" without prompting for a password. After a reboot, I found the the same failure message appeared after entering my username into the login prompt ( non-gui login ), without a password prompt again. I was locked out, but was able to ssh. I ssh'd in via another computer and was able to re-emerge pam, which also allowed me to dispatch-conf to re-create the configs. dispatch conf showed: --- /etc/pam.d/login 1969-12-31 18:00:00.000000000 -0600 +++ /etc/pam.d/._cfg0000_login 2012-04-19 21:25:46.623889448 -0500 @@ -0,0 +1,5 @@ +auth required pam_securetty.so +auth include system-local-login +account include system-local-login +password include system-local-login +session include system-local-login --- /etc/pam.d/passwd 1969-12-31 18:00:00.000000000 -0600 +++ /etc/pam.d/._cfg0000_passwd 2012-04-19 21:25:46.624889574 -0500 @@ -0,0 +1,4 @@ +auth sufficient pam_rootok.so +auth include system-auth +account include system-auth +password include system-auth --- /etc/pam.d/su 1969-12-31 18:00:00.000000000 -0600 +++ /etc/pam.d/._cfg0000_su 2012-04-19 21:25:46.624889574 -0500 @@ -0,0 +1,8 @@ +auth sufficient pam_rootok.so +auth required pam_wheel.so use_uid +auth include system-auth +account include system-auth +password include system-auth +session include system-auth +session required pam_env.so +session optional pam_xauth.so I strongly believe sys-apps/shadow-4.1.5-r1 was the source of the problem. Rebuiling pam did solve the issue... For those who run across this problem, doing so <<before>> rebooting is necessary.
You mean, running etc-update or dispatch-conf helps resolve the issue?
etc-update & dispatch-conf did not show any files needing to be updated until I manually emerged pam.
Same problem after update... on arm netbook sshd stopped, login throw xdm - with user - success, su || root on console - failed... :(
There are files: ._cfg0000_login ._cfg0000_passwd ._cfg0000_su in /etc/pam.d/ & have not files: login, passwd, su.
(In reply to comment #2) > etc-update & dispatch-conf did not show any files needing to be updated > until I manually emerged pam. I didn't have to manually emerge pam - dispatch-conf showed the files immediately after emerging shadow. But I also didn't reboot in between, and I happened luckily to have a root shell open on the machine so wasn't ssh-ing in. Also, I incidentally upgraded sys-auth/pambase just before shadow, because of a version bump.
(In reply to comment #5) > (In reply to comment #2) > > etc-update & dispatch-conf did not show any files needing to be updated > > until I manually emerged pam. > > I didn't have to manually emerge pam - dispatch-conf showed the files > immediately after emerging shadow. But I also didn't reboot in between, and > I happened luckily to have a root shell open on the machine so wasn't > ssh-ing in. Also, I incidentally upgraded sys-auth/pambase just before > shadow, because of a version bump. Did you get the usual notice that files need to be updated in /etc/? I did not -- the problem is that I believe many will not notice there is a problem until they reboot and are locked out of their system. I use my laptop at work then take it home with me -- at which time I usually poweroff. I can see others doing this also, leading to a lockout as the login prompt will fail to prompt for a password.
> Did you get the usual notice that files need to be updated in /etc/? I did > not -- the problem is that I believe many will not notice there is a problem > until they reboot and are locked out of their system. I don't remember, and my terminal scrollback doesn't go that far. I only noticed this problem when I tried to use `su` from a different terminal and got back an authentication error without even a password prompt. Then I checked `qlop -l`, guessed shadow was the culprit, searched the bug tracker, and found this bug. I tried looking for this info in various places (/var/log/portage, /var/tmp/portage) but couldn't find it. Any ideas if it's logged somewhere else I haven't looked? > I use my laptop at work then take it home with me -- at which time I usually > poweroff. I can see others doing this also, leading to a lockout as the > login prompt will fail to prompt for a password. Sure, this is definitely a problem. Especially if someone emerged this version of shadow using `sudo` and subsequently didn't have a root shell from which to run dispatch-conf anyway - luckily I did.
I got hit by this too - ended up booting a Live USB, chrooting, and running etc-update. I think this is a bug because if I open a root shell, start screen, run emerge, detach and log out, I wouldn't be able to log back in after emerge completes to run etc-update. So it would be nice to have a warning in advance to not log out of the root shell before the pam configs are updated.
Portage says to run etc-update at the end of emerge which is sufficient. This *could* use Portage News Item when going stable as a courtesy, but for now, there isn't anything to do.
(In reply to comment #9) > Portage says to run etc-update at the end of emerge which is sufficient. As I said above, you CAN'T run etc-update if you can't re-attach to the screen session... It's not sufficient. So a news item is definitely a good idea.
(In reply to comment #9) > Portage says to run etc-update at the end of emerge which is sufficient. What if emerge is run with sudo? (I haven't tested whether sudo still works with the PAM configs missing.)
Paweł: could you take care of putting together a news item ? i'm not sure if there's a way to automate this ... we could have the pambase package in its pkg_postinst manually take care of the `etc-update` step in /etc/pam.d/ if the existing ones matched a known md5sum. that should handle most people, and for the rest, well shit. Paweł: want to investigate that too ?
*** Bug 412863 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > I think this is a bug because if I open a root shell, start screen, run > emerge, detach and log out, I wouldn't be able to log back in after emerge > completes to run etc-update. So it would be nice to have a warning in > advance to not log out of the root shell before the pam configs are updated. This is exactly what happened to me last night, 2 remote machines in different locations :(
(In reply to comment #11) > What if emerge is run with sudo? (I haven't tested whether sudo still works > with the PAM configs missing.) Yes, sudo still works, as does key-based SSH login, which is how I fixed it.
sudo works if you have it set to: %wheel ALL=(ALL) NOPASSWD: ALL If sudo has to prompt you for a password, it will fail as it won't. Good point on the SSH @Neil, That's why I was able to ssh -- I don't use passwords.
*** Bug 415155 has been marked as a duplicate of this bug. ***
