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 86414 - RFE: sanity checking for password unlocking function
Summary: RFE: sanity checking for password unlocking function
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libuser
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-21 17:41 UTC by Matthew Miller
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: 0.53-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-14 22:48:15 UTC


Attachments (Terms of Use)

Description Matthew Miller 2003-03-21 17:41:30 UTC
Currently, if a user's local password entry is just "!!" (as it well may be if
using kerberos or other non-local authentication), the unlock user functions
will blithely remove this, leaving no password at all. I think it'd be nicer for
the function to fail in this case, and for there to be a separate function like
unlock_if_blank for situations where this behavior is really wanted.

Comment 1 Miloslav Trmač 2004-09-01 19:38:50 UTC
As much as I would like to be able to differentiate between
"user is never meant to log in" and "user has an empty password,
but the account is currently locked":
* existing practice does not support this (shadow-utils use "!!"
  for "never log in", libuser for "empty password, locked"
* it's an incompatible API change
* libuser users have a reasonable right to expect that
  removepass->lock->unlock works and results in an account with no
  password.

Comment 2 Matthew Miller 2004-09-01 19:57:44 UTC
How about the other way around -- a "safe unlock" function, which will
never leave an account unprotected?

Comment 3 Miloslav Trmač 2004-11-14 22:48:15 UTC
libuser-0.53 provides lu_user_unlock_nonempty () and
lu_group_unlock_nonempty(). The Python unlockUser and unlockGroup
functions have an optional 'nonempty' parameter.

Comment 4 Matthew Miller 2004-11-14 22:56:11 UTC
Thank you very much!


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