This appears to be an issue that arises when /etc/passwd and /etc/group aren't correctly synched with their shadow counterparts. To trigger the bug on a broken system, try to login as a user with an valid username but invalid password, then try to login as that user with root's password, and then login as that user correctly, if the system is affected, you fill find that you are root with a broken home directory. The immediate fix for an effected system is to resync the passwd and shadow files by doing the following: -==-cut here-==- pwconv pwunconv grpunconv grpconv pwconv -==-cut here-==- at least that is what worked for me.
This is a realy BIG problem. It is much easier to replicate then desribed. Try to login from a virtual terminal 3 times in a row as a regular user with the wrong password (any password) and finaly enter the correct password. You are now logged in as root. Someone just posted that it can be remotely eploitable if you run a telnet server. This is so big, that until it is fixed, you should recommend disconnecting Gentoo boxes from the Internet. The big priority and severity should be upped to the maximum.
the problem is with pam_pwdb.so flaking out if there are minor issues with the passwd database. It's still a pam_pwdb.so problem -- fix in progress... stay tuned... (replace all occurrences of pam_pwb.so with pam_unix.so in your /etc/pam.d files, particularly system-auth for a quick fix..)
The 4.0.2-r2 shadow package fixes this big bad Gentoo 1.0 bug.
