Hey there,
Here's something I ran into for the first time in my life today (and I don't mean the longest frickin' subject line I've ever written ;)
I was working with a colleague, booting up a recently panicked (I'm assuming, since I wasn't involved when "the incident" happened) SUSE Linux 10 system, when we saw the following error:
Login Failed: Permissions on the password database may be too restrictive.
Or something to that effect. Unfortunately, I don't have the screen to cut-and-paste from (not complaining). We ended up getting this error for regular users and administrative users, including root. It seemed like there wasn't an account available that could log in to the box. Eventually the problem was solved, but it was an interesting situation and, perhaps, some of the following troubleshooting information might be of help to you in the future (So you don't have to boot "rescue" off of CD more than once ;)
Here's how it went down (try to contain your excitement. This is edge-of-your-seat stuff, so, please, go to the bathroom before you continue reading ;)
1. The first thing we did was to try logging in with all the accounts we could think of. None of them worked, although we were relatively sure that they were enabled and had worked previously.
2. Then we did the sanity-check that (interestingly) you don't see too many people do any more: We quit trying to login to the default run level (5 - X-Windows) and tried the same logins we did in step 1 on the machine's local console. At this point, we considered that we may have hit some limit on failed login attempts, but quickly discounted that theory, since our logins had been failing from the start. It's also worth mentioning that this was a newer machine and (as it turned out) had not been attacked in any way that might disable passwords from being accepted.
3. Next, we booted off of CD and ran SUSE Linux in "rescue" mode. This gave us a very easy login. Username: root. No password required. Using "lvscan" we were able to to identify the root partition and ran fsck on all available partitions to ensure that no file system corruption existed.
4. Once all the fsck's came back "OK," we mounted /dev/system/root onto a temporary directory (/tmp/root for instance):
host # mkdir /tmp/root
host # mount /dev/system/root /tmp/root
5. Then we changed directories into what would normally be our /etc directory to look for any obvious signs of damage. None could be found. In fact, it seemed as though the error we were getting was completely erroneous:
host # cd /tmp/root/etc
host # ls -l passwd shadow
-rw-r--r-- 1 root root 25729 Jun 10 05:52 passwd
-r-------- 1 root root 14268 Jun 10 05:51 shadow
Those permissions may seem restrictive, but they're actually required so that users' passwords can remain secure. /etc/passwd should be readable by anyone, but the "passwd" program actually runs "setuid root" so that it can verify the user's password by reading the /etc/shadow file:
-rwsr-xr-x 1 root root 27768 Jul 17 2006 /usr/bin/passwd
6. We added our own user id's to the "wheel" group (root was already a member) and rebooted, to see if that would help, but it didn't. That was lame, I know, but much better than finding out later that it was actually the solution and we never tried it ;)
7. Booting up in rescue mode and mounting the root partition again, we took a look at the /tmp/root/etc/sysconfig/permissions file (We couldn't use Yast's X-Window interface, as explained below). It turns out that the line:
PERMISSION_SECURITY=
was set to paranoid for local security!!!! This was easily fixable by changing it back to the least restrictive of settings (you have easy, secure and paranoid to pick from, I believe):
PERMISSION_SECURITY="easy local"
saved that file and rebooted. All was well :)
The Aftermath:
One interesting thing I noted, when taking a look at the problem afterward, was that "paranoid" local settings were actually set on purpose by another admin (the default for our install image was what we reverted back to - "easy local").
This setting seems like a good idea, because, from the documentation I could find, it purports to make it so that the administrator gets to choose which users can run X sessions and "setuid" programs, although (obviously) it should never be set up and not completely finished and tested before leaving it go ;)
One of the major issues is that, if no one is specifically allowed to run X sessions and/or use setuid programs after this setting is enforced and the machine is rebooted, root is included in the accounts that are denied access to these programs.
The X denial is okay. I can live with that. But not allowing root (and every other account) to use setuid programs makes it impossible for anyone to login. The reason for this is actually pretty simple. When login asks for your password, in simplistic terms, it employs "passwd" (a "setuid" program, as shown above) to read your user entry from /etc/shadow and confirm that your password is actually correct. Since no one is allowed to use "setuid" programs, no one (including root) can login (Via X, remotely or even directly on the local console).
Crazy, but fun for a while ;) Hopefully this helps someone out there :)
Cheers,
, Mike
Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.
