Bug 7290 - Users without password can no longer log in
Summary: Users without password can no longer log in
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: passwd
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-24 14:39 UTC by maavl
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-05 20:19:41 UTC
Embargoed:


Attachments (Terms of Use)

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 ridgewr1.mil (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.


Note You need to log in before you can comment on or make changes to this bug.