|Summary:||Users without password can no longer log in|
|Product:||[Retired] Red Hat Linux||Reporter:||maavl|
|Component:||passwd||Assignee:||Cristian Gafton <gafton>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-02-05 20:19:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description maavl 1999-11-24 14:39:13 UTC
After upgrading from RedHat 5.1 to 6.1 (in any case for all core components such as kernel, initscripts, util-linux, pam) I noticed that my kids, whom I had given accounts without passwords, could no longer log in. They were still mentioned in the relevant files in /etc, with an empty string for the encrypted password, but any attempt to log in was refused. An attempt as root to give them the empty string as password (which is almost as good as no password) was refused by passwd, on the (understandable) grounds that the new password was way to short, but it would have been nice if there was some overriding mechanism. I did finally succeed in giving them empty passwords using the control-panel; somehow it must have convinced passwd to accept that. However, something must be wrong with this procedure, because the next time I wanted to become root, I found that the root password, which I never had attempted to change in any way, was no longer accepted! I had no records of the old encrypted root password, so I cannot tell if it had been altered, but I suppose it had. In any case I did manage to reset the root password by booting into single user mode, so everybody is happy again, but I surely did have quite a scare there! Maybe it was deemed to dangerous in 6.1 to allow any users without passwords, but I think that users should at least been given a chance to set one, rather than being simply refused (yes, I do realise this allows anybody else to change their password before they can themselves, but that is inevitable and no different from the situation before). And I think that in some situations, e.g., a PC at home, the risk is quite acceptable, and it should be possible to deliberately choose to have such logins.
Comment 1 ridgewr1 1999-12-30 15:08:59 UTC
from email@example.com (Richard Ridgeway). You will also notice that any attempt by root to alter any user whose password is set to null fails, i.e. "user1::100:20::/home/user1:/bin/tcsh". For example, when root enters the command "passwd user1", and then enters in a valid password twice as directed, the password field for user1 as shown above (::) does not change. However, if root places "junk" in the password field of the entry for user1, i.e. "user1:junk:100:20::/home/user1:/bin/tcsh", and then enters "passwd user1", and enters in a valid password twice as directed, the "junk" entry in the password field is replaced by the valid scrambled password, and all works OK. This example is from a RedHat v6.1 upgrade from 5.2 where the upgrade defaults of activating the /etc/shadow and MD5 (?) were not performed.
Comment 2 Bill Nottingham 2000-02-05 20:19:59 UTC
This should be fixed in the latest pam/pwdb pacakges in Raw Hide.