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:
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.