CODEWITHSUNDEEP
androidandroid-intentbroadcastreceiverandroid-contentproviderandroid-permissions
gurghet
gurghet

Reputation: 7706

How to grant permissions only to the creator of an URI

I have an application, say ApplicationProvider, which holds a provider and a receiver. Another application, say ApplicationCreator, creates an element on the provider through an intent. The ApplicationProvider get the intent and creates the element accordingly.

Now I would like ApplicationCreator to be the only one to hold the rights to access that element. So if another application tries to access that element, this generates some kind of error.

What is the best way to do so? I came up with two possible solutions, but I don't like any of them.

1) ApplicationProvider denies any direct access to the provider, instead uses the receiver to get the intents which are sent through intentForResult, so the receiver can check the caller, verify that is the original caller who created the element and grant access. Other applications would get denied because they hold a different uid. Since there is no easy way to forge the uid, this system works.

2) Any application can send intents to the provider but in the manifest i specify all the path-level permission to the single uris that are created. I manually issue an update to the application every time someone wants so create a new element.

=========================================

Additional information:

It would be ideal if different applications could put different elements and be able to retain the rights to modify those elements they created and also grant permission on those elements to whom requested said permission.

A---> +--------+            A creates content
      |   pro  | <---B      B asks permission
A<----|   vid  |            the provider forward permission
A---->|   er   |            A grant permission
      |        | --->B      B is given permission and can access A's stuff
      +--------+

Upvotes: 3

Views: 542

Answers (2)

hackbod
hackbod

Reputation: 91341

I would suggest the uid approach, but there is no reason for this to go indirectly through a receiver. Just store the owning uid for each row in your database, and on incoming calls to the content provider use Binder.getCallingUid() to retrieve the uid of the current caller which you can validate against the row they are operating on.

Upvotes: 2

user656588
user656588

Reputation:

Here are my thoughts on this topic. No code is provided, since I did not implement anything. Also, I'm not entirely sure that this solution is entirely secure.

First, authentication.

Every client who wants to use your content provider needs a key. Each client fetches one key from your application (maybe implement a content provider for that). A random sequence of letters / numbers should be fine. This key is stored within your application and the clients application, somewhere where noone else has access, i.e. a private database / preference property.

This key is used to authenticate a client application with your content provider. On each request, this key (maybe a hash of the key) is included within the request uri (much like API keys when using REST web services). Your application checks whether the provided key was previously generated. If that is the case, authentication is successful.

Next, authorization.

Each element in your database has a field ownerKey. When creating new elements, this field is filled with the key provided with the request. When accessing / modifying / deleting elements, your content provider should check whether the stored key matches the submitted key. Only perform the operation if the keys match.

Additional thoughts.

  • The whole point is that the random keys generated by your application stay private. I'm not sure whether it is possible for a third party to intercept interaction between a client application and a content provider. You might want to investigate this before writing any code.
  • Specifying a key on each request could be optional. When omitting a key during element creation, those elements do not have an ownerKey and thus are allowed to be accessed and modified by anyone without authentication/authorization.

I hope this helps somewhat.

Upvotes: 5

Related Questions