Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 603377 - user added from CLI, when "unlocked" from GUI, easily left with NULL password
user added from CLI, when "unlocked" from GUI, easily left with NULL password
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-users (Show other bugs)
6.0
All Linux
high Severity medium
: rc
: ---
Assigned To: Nils Philippsen
Miroslav Vadkerti
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-12 14:42 EDT by Bowe Strickland
Modified: 2010-11-10 16:44 EST (History)
3 users (show)

See Also:
Fixed In Version: system-config-users-1.2.100-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 16:44:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bowe Strickland 2010-06-12 14:42:56 EDT
If a user is added from the command line, but no password is assigned, /etc/shadow is initialized with "!!" in field 2.

When examining said user's properties from s-c-users, "Account Info" panel reports password as locked.

Novices can easily choose to "unlock" the account and exit, and the account is left with a NULL password allowing password-less entry.  

Reproduced on Fedora 13 and RHEL6 beta.  Probably many earlier releases as well...
Comment 2 RHEL Product and Program Management 2010-06-12 15:12:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Eduard Benes 2010-06-18 11:31:13 EDT
Still reproducible with

$ rpm -q system-config-users
system-config-users-1.2.94-1.1.el6.noarch
Comment 4 Nils Philippsen 2010-06-22 06:47:08 EDT
Hmm, I've looked into this and found that there's no straight-forward way to check "if I unlock this user, will it get an empty password?". The underlying libuser library supports a number of different backends -- local files, ldap, possibly sasl in the future (the code exists, but is not packaged ATM) -- where locking accounts is done differently. This means I can't just check whether 'pw_passwd' or 'sp_pwdp' of a user entity is '!!' since this is not the way all backends lock accounts.

The only remotely portable way I can think of right now is to unlock the user entity and then check if the entity password is empty, e.g.:

...
admin = libuser.ADMIN()

userEnt = admin.lookupUserByName(username)

if admin.userIsLocked(userEnt):
    admin.unlockUser(userEnt)
    pw_empty = False
    for k in ('sp_pwdp', 'pw_passwd'):
        if userEnt.get(k, [None]) == "":
            pw_empty = True
            break

    if pw_empty:
        admin.lockUser(userEnt)
        # warn about empty password, focus password field, etc.
...

Note that this is also not really portable as it hard-codes the backend-specific password fields (probably incompatible with any future backends) and introduces a short window in which the user account is unlocked with an empty password (which we wanted to avoid in the first place).

At the moment I don't really see a safe and portable way without changes in libuser, e.g. additional userPassIsEmpty()/groupPassIsEmpty() methods which tell the application whether the password of a user is empty, independent of the backend in which the account is stored and regardless of whether the account is locked or not.

Mirek, how do you see this? Have I missed something?
Comment 5 Miloslav Trmač 2010-06-22 07:21:12 EDT
There is
   admin.unlockUser(userEnt, [nonempty=]True)
which raises RuntimeError if the resulting encrypted password would be empty.

I'm afraid there is no reliable way to detect if the RuntimeError was caused by an empty password or by other causes (trying unlockUser with nonempty=False would make the account temporarily unlocked, which is not a good idea).  The RuntimeError is accompanied with a (probably localized) error message, so you should be able to simply display that.

(unlock*(nonempty=True) does not try to detect a non-empty encrypted password hash of an empty string - but that is unlikely to ever happen in practice.)
Comment 7 Nils Philippsen 2010-06-30 05:32:27 EDT
Fixed in git:

commit 229b86f2ad2a4c67496e2f819d83819d83c31bd5
Author: Nils Philippsen <nils@redhat.com>
Date:   Wed Jun 30 11:27:08 2010 +0200

    prevent unlocking users with empty passwords

This patch excepts the RuntimeError which "admin.unlockUser(userEnt, [nonempty=]True)" raises and displays the supplied (translated) error message, then sets the password fields of the dialog sensitive and sets the "Local password is locked" checkbox.
Comment 9 Miroslav Vadkerti 2010-08-13 05:59:40 EDT
VERIFEID as fixed in system-config-users-1.2.104-1.el6

NEW PACKAGE - system-config-users-1.2.104-1.el6:
Unlocking the user failed because:
unlocking would make the password field empty

OLD PACKAGE - system-config-users-1.2.94-1.1.el6:
/etc/shadow after reproducing the bug:
jozef::14834:0:99999:7:::
Comment 10 releng-rhel@redhat.com 2010-11-10 16:44:03 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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