Skip to content
Commit 49e179cb authored by Hai Zhang's avatar Hai Zhang
Browse files

Fix allowlisting restricted permissions for secondary users on app

upgrade.

restorePermissionState() runs for all users and drops any restricted
permission grant without an allowlist, however we may not have the
allowlist ready for other users when package manager notifies us of a
package install for one of the installed users, as the callback API
is (and should be) per-user. To be more specific about this issue:

The way this used to work is very fragile and relies on the
implementation detail that things happen in restorePermissionState()
with the following order:

1. Implicit permissions are considered new if there wasn't any
permission state for it.
2. Then permission restrictions are applied and since a new permission
state won't have any allowlist, the APPLY_RESTRICTION flag is added
and the permission is made revoked.
3. setInitialGrantForNewImplicitPermissionsLocked() is called after
permission restrictions are applied, and doesn't respect the
APPLY_RESTRICTION flag, so that the new implicit permission is
granted.

And if the allowlist is added in time before the next
restorePermissionState() call, the permission restriction mechanism
will see the allowlist and not revoke the implicit permission grant.

However since our callback API from package manager is per-user, and
we want to properly support adding instead of replacing the allowlist
for each user (the existing allowlist for each user can be different
so addition has to be done with get-add-set per-user), the allowlist
addition has to be per-user, and this would introduce a
restorePermissionState() call that's too early for the other users.

Thanks to the refactoring that happened in S, the permission state
objects are now per-UID instead of per-package, so that the updates
are actually being perform per-user now, and we just need to expose
the capability for restorePermissionState() to be per-user instead of
hard-coded to run for all users. Then we can prepare the permission
state and allowlist for each user independently and fix this issue.

Fixes: 191381905
Test: atest SplitPermissionTest --user-type secondary_user
Test: atest CtsPermission2TestCases
Test: atest CtsPermission2TestCases --user-type secondary_user
Test: atest CtsPermission3TestCases
Test: atest CtsPermission3TestCases --user-type secondary_user
Change-Id: I6973fd54281a3b15e5206db286eab8b918709a19
parent 80b02a06
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment