summaryrefslogtreecommitdiff
path: root/tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp
diff options
context:
space:
mode:
authorJeff Sharkey <jsharkey@android.com>2018-09-24 13:23:57 -0600
committerandroid-build-team Robot <android-build-team-robot@google.com>2018-10-20 00:17:43 +0000
commit35f31cbac405b20ec1cd55714609c88f98a99c14 (patch)
treec30a382d15b80050669f7aa60705492939957634 /tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp
parent553bb7c6a2b2c70b1cd011aec9bf9c151818d8c3 (diff)
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 Merged-In: Ibadbfa4fc904ec54780c8102958735b03293fb9a Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a (cherry picked from commit c084ddbf826b25808c4553e4b5992c6723eac4ea)
Diffstat (limited to 'tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp')
0 files changed, 0 insertions, 0 deletions