Grant the ACTIVATE_PLATFORM_VPN appop if VPN app has CONTROL_VPN

This makes the VpnManager APIs consistent with VpnService, ensuring that apps relying on CONTROL_VPN and a separate consent dialog (per CDD) can work properly using the VpnManager. Without this patch, there is an inverted incentive to use the VpnService.

As a workaround, apps using this with CONTROL_VPN already can/do work around this by calling VpnService.prepareAndAuthorize().

Bug: 232051081
Test: atest FrameworksNetTests:VpnTest
Change-Id: I0e0566bb8fed2f9330889e031175c33d499fa855
This commit is contained in:
lucaslin
2022-07-01 11:11:10 +08:00
committed by Lucas Lin
parent edc13cc241
commit deda023922

View File

@@ -1095,7 +1095,7 @@ public class Vpn {
// Except for Settings and VpnDialogs, the caller should be matched one of oldPackage or
// newPackage. Otherwise, non VPN owner might get the VPN always-on status of the VPN owner.
// See b/191382886.
if (mContext.checkCallingOrSelfPermission(CONTROL_VPN) != PERMISSION_GRANTED) {
if (!hasControlVpnPermission()) {
if (oldPackage != null) {
verifyCallingUidAndPackage(oldPackage);
}
@@ -2056,6 +2056,10 @@ public class Vpn {
"Unauthorized Caller");
}
private boolean hasControlVpnPermission() {
return mContext.checkCallingOrSelfPermission(CONTROL_VPN) == PERMISSION_GRANTED;
}
private class Connection implements ServiceConnection {
private IBinder mService;
@@ -3857,8 +3861,10 @@ public class Vpn {
Binder.restoreCallingIdentity(token);
}
// TODO: if package has CONTROL_VPN, grant the ACTIVATE_PLATFORM_VPN appop.
// This mirrors the prepareAndAuthorize that is used by VpnService.
// If package has CONTROL_VPN, grant the ACTIVATE_PLATFORM_VPN appop.
if (hasControlVpnPermission()) {
setPackageAuthorization(packageName, VpnManager.TYPE_VPN_PLATFORM);
}
// Return whether the app is already pre-consented
return isVpnProfilePreConsented(mContext, packageName);