CODEWITHSUNDEEP
androidpermissions
Belgikoi
Belgikoi

Reputation: 615

Android - ContentProvider - custom permissions

I've a problem with content provider and custom permissions.

  1. Let's suppose that App A have a content provider containing wonderful informations. These informations are a little bit intrusive, that's why it's better to have a permission to read them.

  2. Let's suppose that App B is a 3rd party application and want to access to the content provider of A.

  3. Let's suppose that the permission to read into the content provider is "com.custom.a.readpermission".

  4. In A manifest, there is :

    <permission android:name="com.custom.a.readpermission"/>

<provider android:name="com.a.provider.MyProvider"
          android:exported="true"
          android:authorities="com.a.provider.MyProvider"
          android:readPermission="com.custom.a.readpermission"/>

  5. In B manifest, there is :

    <uses-permission android:name="com.custom.a.readpermission"/>

So, now, if I install A; after, I install B. B can access to the data.

But, if I install B before A, I get :

java.lang.SecurityException: Permission Denial: opening provider com.a.provider.MyProvider requires com.custom.a.readpermission

So, how to manage a custom permission in that case ?

Upvotes: 1

Views: 1082

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006869

So, how to manage a custom permission in that case ?

Your primary options are:

  1. Use a built-in system permission, as opposed to a custom one. This is a good idea in general, if the nature of the sensitive data is similar to other data already defended by built-in permissions.

  2. Catch this exception and tell the user that they need to uninstall A and B and install them in the proper order.

  3. If A and B are both by the same author, use a protectionLevel signature permission and have the same <permission> element in both A and B. Then the installation order will not matter, and the user won't be bothered with any prompts to agree to this permission.

However, bear in mind that prior to Android 5.0, the fact that option #3 works means that any app installed before A could do the same thing as B does, except downgrading the protectionLevel from signature to normal. This is a known vulnerability. Android 5.0 requires that custom permissions are defined on a "first one in wins" basis, and the second and subsequent apps trying to define the same <permission> have to be signed by the same signing key as the app that actually did define it.

In truth, permissions are great for pre-installed apps and the OS itself, but defining custom permissions at the app level is... less than great.

Upvotes: 3

Related Questions