Yesterday I applied the su security patch to my openSuSE 11.2 x86_64 system.
After applying the patch, any attempt at su failed, and after rebooting the system earlier this morning any login (root, user, otherwise) fails with a “Permission Denied”.
Is it possible that the su update somehow messed up my (standard) pam settings?
Strange I have not seen such an update. What repositories do you have active?
zypper lr -d
I’m still trying to break in to the system (to be able to check that out - currently even root on the console can’t log in - attempting to hack the login pam module from a rescue boot to get me in, failing so far).
Unfortunately I need this system working more than I need to understand this problem 
I’m going to head into a re-install (having first saved off /var from a rescue boot, so as not to accidentally loose e-mail etc).
Thanks for taking the time to respond 
- sorry I couldn’t provide more info (although I’ll save off /etc as well, maybe the zypper config file from in there may give some idea as to what could have happened as a post mortem).
This is really an odd problem… right now the only way to “break in” I can think of is using a live-system such as Knoppix. Look into /etc/zypp/repos.d for the used repositories (as asked by gogalthorp), and while you’re at it, copy /var/log/zypp/history as well, that’s a chronlogical logfile of zypper.
What do you mean by ‘su-patch’?
Resettng the passwords didn’t work - it’s as if pam just decided that no-one was allowed any kind of access. Even fiddling with the pam config (not something I’ve really got a clue about) from a rescue boot didn’t help (having mounted the “real” root, etc)…
Unfortunately the backups I took was less than perfect, I only got directory entires, no actual file content, for a lot of /var (unfortunately inclding zypper.log & /var/log/zypp/history) & /etc but the content of /etc/zypp/repos.d was
1.2.repo 11.2_1.repo 11.2_2.repo Contrib.repo Updates_for_openSUSE_11.2-0.repo openSUSE 11.2-0.repo openSUSE-11.2-Non-Oss.repo openSUSE-11.2-Oss.repo repo-debug.repo repo-source.repo
Back up and running now, on a fresh install. All that now remains is to reconstruct the mail server setup.
Still trying to understand where your “su” update came from. Very odd. If you see it again don’t apply it but let us know so someone can investigate.
Will do - thanks
I think I saw a “sudo” rpm update on the official Novell/SuSE-GmbH “update” repos.
One can check to see what applications were installed by typing:
rpm -qa --last
or if that scrolls by too fast
rpm -qa --last > my-rpms.txt
and open my-rpms.txt with a text editor.
EDIT : I’m not at a Linux PC currently so I can not check to see how good/bad my memory may be.
…] or if that scrolls by too fast …]
This way is even more convenient:
rpm -qa --last | less
At the Brainshare earlier this week, one of the labs had an eerie resemblence to the error I was seeing.
For the benefit of those coming after, something to try in these kind of “can’t log in” situations, is to try the following:
At the boot prompt, type in the line
INIT=/bin/bash
This will boot you into the root account with the root partition loaded. NB that things like proc & sysfs won’t yet be mounted, so you won’t be able to start eg the network stack without further steps.
Once you’re in, go take a look at the file
/etc/nsswitch.conf
This controls which name service the system will use for authentication - to make sure that you’re really using the local files use the “file” keyword (the file is pretty well commented at the top). That may well help you get back in to the system (at least, that was the trick in the lab).
That file gets “called” before the PAM stuff starts, so it’s worth checking before you go in and try randomly messing up PAM as I did earlier