Summary: | sys-apps/shadow-4.1.5-r1 causes system lockout | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Beshoy Girgis <odslabs> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | alecm_88, bugs.gentoo.org.list, gottlieb, keshav.kini, kripton, leho, odslabs, pam-bugs+disabled, phajdan.jr, rose |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Beshoy Girgis
2012-04-20 03:51:29 UTC
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. *** |