Oh, I just realized also, in case anyone wants to know, you can
directly call Binder.getCallingUid(), and you can see examples in
android/packages/providers/DownloadProvider/src/com/android/providers/
downloads/DownloadProvider.java

On Aug 18, 1:21 pm, Jonathan Herriott <herri...@gmail.com> wrote:
> Yeah, sorry, I just noticed the ability to get the Uid in
> IBinder.Stub.  I didn't realize this at first since my interface calls
> functions on the Service, and I was checking the service for the
> permissions.
>
> *sigh*
>
> On Aug 18, 12:53 pm, Dianne Hackborn <hack...@android.com> wrote:
>
>
>
> > You -can't- do this in onBind(), since for performance reasons the onBind()
> > is called only once for each intent, so we don't need to do multiple IPC
> > hops for each request (into the system and then into the service).
>
> > And if what you are interested in protecting is an interface returned by
> > onBind()...  well then, you -have- an interface, which you can do all kinds
> > of your own protecting by doing checks against incoming uids.  For example,
> > you could have 10 methods on the interface that use
> > Context.checkCallingPermission() to allow access to each of them based on
> > different permissions.  Or you could have one method that services as a
> > factory, returning another interface, and in the factory method you do your
> > permission check which will thus provide full access to the secondary
> > interface.
>
> > For content provider, you can do uid checks in any of the incoming calls.
> > You can also protected the provider in the manifest with different read and
> > write permissions, and in Donut you will be able to specify other
> > permissions in the manifest for specific paths.
>
> > I don't think we need a feature request. :)
>
> > On Tue, Aug 18, 2009 at 12:37 PM, Jonathan Herriott 
> > <herri...@gmail.com>wrote:
>
> > > Hi Dianne,
>
> > > Should I bother requesting this in b.android.com, since I would like
> > > to sandbox data for each application that connects to my service.  As
> > > far as I can tell, there seems to be no way when receiving an intent
> > > in onBind() that will inform me of the uid of the calling
> > > application.  Also, I would also like to be able to do the same thing
> > > in a ContentProvider, but again, there seems to be no function to
> > > obtain this information.
>
> > > Thanks,
> > > Jonathan Herriott
>
> > > On Aug 18, 12:16 pm, Dianne Hackborn <hack...@android.com> wrote:
> > > > There isn't any way to do this for a service, though you can find out 
> > > > the
> > > > calling intent for an activity when the caller is waiting for a result.
> > > > Most security is enforced in the system either by associating 
> > > > permissions
> > > > with components in the manifest, or checking the uid of incoming IPC
> > > calls
> > > > to services and content providers.
>
> > > > On Tue, Aug 18, 2009 at 11:03 AM, Jonathan Herriott <herri...@gmail.com
> > > >wrote:
>
> > > > > I was wondering if there is a way to determine who passed an intent to
> > > > > my application.  For example, I have a service, that I want to act
> > > > > differently depending on who passed the intent (for security
> > > > > reasons).  I'm trying to sandbox each calling application, so they
> > > > > only have access to their data stored in my application.
>
> > > > > For it to be secure, I cannot trust any application to be truthful
> > > > > about the identifying data it is passing into my service.  Therefore,
> > > > > I need some system way of identifying who sent the intent in a way
> > > > > that the calling application cannot change that information.  I don't
> > > > > know if it is possible, but I can't find anything in the Intent class,
> > > > > and I was wondering if there may be another structure which does what
> > > > > I want it to.  If it is not possible, I would like to get some type of
> > > > > mechanism to do this in the roadmap.
>
> > > > > Thanks,
> > > > > Jonathan Herriott
>
> > > > --
> > > > Dianne Hackborn
> > > > Android framework engineer
> > > > hack...@android.com
>
> > > > Note: please don't send private questions to me, as I don't have time to
> > > > provide private support, and so won't reply to such e-mails.  All such
> > > > questions should be posted on public forums, where I and others can see
> > > and
> > > > answer them.
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
>
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support, and so won't reply to such e-mails.  All such
> > questions should be posted on public forums, where I and others can see and
> > answer them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to