Bug 86414

Summary:	RFE: sanity checking for password unlocking function
Product:	[Fedora] Fedora	Reporter:	Matthew Miller <mattdm>
Component:	libuser	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	0.53-1	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-14 22:48:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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!