tag 48d2cb6236fccbd35abe0e58f0cd966458847b55
tagger The Android Open Source Project <initial-contribution@android.com> Mon Jun 01 16:31:24 2020 -0700
object 845bb9b3e243deb49be33c75f835893dba50492f

Android 9.0.0 Release 57 (6454888)

commit 845bb9b3e243deb49be33c75f835893dba50492f
author Jeff Sharkey <jsharkey@android.com> Mon Sep 24 13:49:30 2018 -0600
committer Rohit Yengisetty <rngy@google.com> Wed Oct 17 11:09:38 2018 -0700
tree b332e73a9793b0d074d86cd873cf45fdf808d1c9
parent cf1969a847b6aa8d39c01eacb1ba15092df9781e

Recover shady content:// paths.

The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.

This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths.  Consider this example:

    <path-permission android:pathPrefix="/private" ... />

    uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);

    content://com.example//private

The Uri above will pass the security check, since it's not
technically a prefix match.  But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.

Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.

Bug: 112555574
Test: atest android.appsecurity.cts.AppSecurityTests
Test: atest FrameworksCoreTests:android.content.ContentProviderTest
Change-Id: Ia62aa19b7d554b806b29875eb6e397adfe69d23b
Merged-In: Ia62aa19b7d554b806b29875eb6e397adfe69d23b
(cherry picked from commit bc62467b7320d77868c3d7a44596f6e96eca2167)