|Summary:||user added from CLI, when "unlocked" from GUI, easily left with NULL password|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Bowe Strickland <bowe>|
|Component:||system-config-users||Assignee:||Nils Philippsen <nphilipp>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Miroslav Vadkerti <mvadkert>|
|Version:||6.0||CC:||mitr, mvadkert, pknirsch|
|Fixed In Version:||system-config-users-1.2.100-1.el6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-11-10 21:44:03 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Bowe Strickland 2010-06-12 18:42:56 UTC
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 19:12:54 UTC
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 15:31:13 UTC
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 10:47:08 UTC
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 11:21:12 UTC
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 09:32:27 UTC
Fixed in git: commit 229b86f2ad2a4c67496e2f819d83819d83c31bd5 Author: Nils Philippsen <firstname.lastname@example.org> 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 09:59:40 UTC
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 email@example.com 2010-11-10 21:44:03 UTC
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.