Don't remove permission when cleaning up orphaned tree on uninstall

This is fixing a security bug in a relatively safe way. Fundamentally
this situation shouldn't be happening. It's an artifact of the way that
the manifest parsing is loose with types. We can consider a more
thorough and upstream fix for upcoming OS releases, but for impact risk
mitigation this is a relatively constrained change.

Bug: 225880325
Test: Tests are included for the more thorough fix.
Change-Id: I86801109ce2d9c2750c6dfef4bb0425df0ab135e
Merged-In: I86801109ce2d9c2750c6dfef4bb0425df0ab135e
(cherry picked from commit d8572e2747)
This commit is contained in:
Joe Castro
2022-10-27 00:17:32 +00:00
parent e8072d9849
commit 02b90551b9

View File

@@ -4215,7 +4215,6 @@ public class PermissionManagerServiceImpl implements PermissionManagerServiceInt
}
boolean changed = false;
Set<Permission> needsUpdate = null;
synchronized (mLock) {
final Iterator<Permission> it = mRegistry.getPermissionTrees().iterator();
while (it.hasNext()) {
@@ -4234,26 +4233,6 @@ public class PermissionManagerServiceImpl implements PermissionManagerServiceInt
+ " that used to be declared by " + bp.getPackageName());
it.remove();
}
if (needsUpdate == null) {
needsUpdate = new ArraySet<>();
}
needsUpdate.add(bp);
}
}
if (needsUpdate != null) {
for (final Permission bp : needsUpdate) {
final AndroidPackage sourcePkg =
mPackageManagerInt.getPackage(bp.getPackageName());
final PackageStateInternal sourcePs =
mPackageManagerInt.getPackageStateInternal(bp.getPackageName());
synchronized (mLock) {
if (sourcePkg != null && sourcePs != null) {
continue;
}
Slog.w(TAG, "Removing dangling permission tree: " + bp.getName()
+ " from package " + bp.getPackageName());
mRegistry.removePermission(bp.getName());
}
}
}
return changed;