DPM: Fix isActivePasswordSufficient for non-FBE devices
For non-FBE devices (devices will full disk encryption or no encryption
at all) the password metrics are not kept in plaintext anymore, so it
is not possible to evaluate the sufficiency of the password when new
password quality requirements are set. Instead, the sufficiency value is
stored in a checkpoint that gets loaded after boot and used before the
user has entered any credentials.
However this checkpoint value was not evaluated correctly (there was a
circular dependency between setting it and reading it) and was not
stored on the right DevicePolicyData object.
Fix the checkpoint value to be the correct one and stored on the right
object, by doing the following:
* Removing the short-circuit introduced in ag/2866930.
* Change the default checkpoint value to true, to prevent re-introducing
b/63887564, and because a newly-created profile, before any password
requirements are set, has a sufficient password.
* Get rid of the circular dependency between setting and reading
mPasswordValidAtLastCheckpoint, by extracting from
isActivePasswordSufficientForUserLocked a function that does not look at
the checkpoint value.
* Store the checkpoint value in the DevicePolicyData object of the
credential owner, as this is where isActivePasswordSufficient reads it.
More details can be found in https://docs.google.com/document/d/15CRewlsy1lyonjAWg3VmhLC5jAyVKazUMKlcPnnId58/edit#
Bug: 71697938,73347414
Test: cts-tradefed run commandAndExit cts-dev -s 127.0.0.1:56619 -a x86_64 -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceAdminHostSideTestApi23#testResetPassword_nycRestrictions -l DEBUG on a gce instance.
Change-Id: Ide5b2e53cf100b087822844ca51b3bc69e7ddf82
1 file changed