diff options
| author | 2022-11-16 22:07:34 +0000 | |
|---|---|---|
| committer | 2022-11-17 01:03:58 +0000 | |
| commit | b3cb7776c0d3ffd760ecf05e31d753311d55e657 (patch) | |
| tree | 049246387059082cafdb63d9449261afe612b206 /services/coverage/java | |
| parent | 30a76b53abc60492c52630d0d8b94ececb7febb5 (diff) | |
LSS: clear calling identity after permission check in checkCredential()
Since commit 3d5653e11ec8 (http://ag/19599753), the call to
IStorageManager.unlockUserKey() after credential verification is done
directly by LockSettingsService, instead of indirectly by
IActivityManager.unlockUser(). IStorageManager.unlockUserKey() requires
the STORAGE_INTERNAL permission, which
LockSettingsService.checkCredential() doesn't have if it is called via a
Binder IPC from Keyguard (SystemUI). This causes an exception that
crashes SystemUI. (SystemUI has the ACCESS_KEYGUARD_SECURE_STORAGE
permission, and various other permissions, but not STORAGE_INTERNAL.)
Fix this by clearing the Binder calling identity in checkCredential()
just after the ACCESS_KEYGUARD_SECURE_STORAGE permission is checked.
This matches the very similar method verifyCredential().
The reason this bug wasn't noticed earlier is because the
above-mentioned CL happened to change IStorageManager.unlockUserKey() to
use @android.annotation.EnforcePermission instead of an explicit
permission check. Unfortunately, the permission annotations have had a
bug that made them not actually work properly (b/241171714). That bug
was just fixed yesterday, exposing this issue.
Test: can now unlock (via the UI) a device that has a PIN set.
Bug: 259401557
Change-Id: I5be5f086ac9405a9f3fb8d7641bd4a5cbb436208
Diffstat (limited to 'services/coverage/java')
0 files changed, 0 insertions, 0 deletions