开发者

Android Framework: System service does not get permission(s)

开发者 https://www.devze.com 2023-02-08 11:18 出处:网络
I added a system service (not an app) into the Android framework (hence running in the system_process). Via Binder.getCallingUid() I can determine the calling process/app. So far so good.

I added a system service (not an app) into the Android framework (hence running in the system_process). Via Binder.getCallingUid() I can determine the calling process/app. So far so good. But if my service tries to use other system services (e.g. the LocationManager) a SecurityException is thrown because LocationManager thinks it is called by the original app that called my service.

From what I understood, system services have all permissions by default, so this should not be the case, should it?

From programming4.us/Mobile/1304.aspx: Binder services are free to make other binder calls, but these calls always occur with the service’s own identity (UID and PID) and not the identity of the caller.

Here some code to illustrate the problem:

public class MyService implements IInterface {

    public IBinder asBinder() {
        return mBinder;
    }

    private final IMyService.Stub mBinder = new IMyService.Stub() {

        public void doSomet开发者_如何转开发hing() {
          int uid = Binder.getCallingUid(); // uid of the calling app
          int myUid = Process.myUid(); // my uid == 1000
          ...
          try {
           ILocationManager lm = ILocationManager.Stub.asInterface(ServiceManager.getService("location"));
           Location myLocation = lm.getLastKnownLocation(LocationManager.GPS_PROVIDER);
          } catch (Exception e) {
             SecurityException is thrown. Requires ACCESS_FINE_LOCATION
          }
        }

    };
}

Thanks in advance for any help or comments!


I haven't tried this myself (yet, however I will come Monday since I'm currently facing exactly the situation you're describing): the Binder has two methods "clearCallingIdentity" and "restoreCallingIdentity" which may be useful to us. If I interpret the documentation correctly, here's how I believe they work.

The first method clears the identity of the incoming IPC so that when you access the LocationManager, you do so using your own identity and not your caller's. It returns a long value that you pass to the second method afterwards to restore the caller identity. This should enable you to pass the LM's permissions check because you will effectively be calling it from system_process (i.e. the same process the LM is in).

0

精彩评论

暂无评论...
验证码 换一张
取 消