Remove the overlapping uid range check

The overlapping uid range check will stop the uid update if the
existing range could cover the new updated rules. E.g. Update
range {0-10010, 10011-99999} to replace the existing range
{0-99999}.

The overlap uid range check was introduced in S as a safety
check, not for a bug fix. The uid range update relies on rules
updated from ConnectivityService. If unexpected duplicate uid
range rules are added to netd, they may mess up the ip rules.
Netd is nearly stateless that it does not know what is currently
set in IP rules but relies on the uid ranges stored in netd. So it
fundamentally requires the correctness of binder calls from the
upper layer. The uid ranges update is already correctly calculated
in ConnectivityService before updating to netd.

Alternative fix for the issue is trying to address the design
in ConnectivityService to remove the old uid range first before
adding new ranges. The problem here is that this may cause
packets leakage that packets are not subject to any uid rules
during the rule update. This would not be a proper fix for the
issue.

Also consider that this overlap check was started from S. This
may break the design in S devices if we only update design in
netd since netd is platform code unlike ConnectivityService that
is in a mainline module. This is OK because the possibility in
API surface to update uid range is started from T in VpnManager
that is also a platform code. The VPNs created from other
sources(legacy VPN or VpnService) would need to reconnect to
update the uid range. The new uid range update will result in
a new VPN network. The overlap check was not actually used in
S devices. That is, it's not really necessary in current design.
Remove this check does not actually introduce other legacy
issue, either.

Bug: 243900420
Test: cd system/netd ; atest
Test: manually test with VPN to exclude some uids and check the
      result
Change-Id: I4b26e4f5371cdce90b2595c82798ecc46963a92e
(cherry picked from commit 65bc4ea7f13dd8e870eaab2d5ad0e89e54a29c85)
Merged-In: I4b26e4f5371cdce90b2595c82798ecc46963a92e

0 files changed, 0 insertions, 0 deletions