Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 7290

Summary: Users without password can no longer log in
Product: [Retired] Red Hat Linux Reporter: maavl
Component: passwdAssignee: Cristian Gafton <gafton>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-05 20:19:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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 (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.