Bug 86414 - RFE: sanity checking for password unlocking function
RFE: sanity checking for password unlocking function
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libuser (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-21 12:41 EST by Matthew Miller
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 0.53-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-14 17:48:15 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 Matthew Miller 2003-03-21 12:41:30 EST
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 15:38:50 EDT
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 15:57:44 EDT
How about the other way around -- a "safe unlock" function, which will
never leave an account unprotected?
Comment 3 Miloslav Trmač 2004-11-14 17:48:15 EST
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 17:56:11 EST
Thank you very much!

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