关闭

android IPC通信中的UID和PID识别

262人阅读 评论(0) 收藏 举报
 android IPC通信中的UID和PID识别

    IPCThreadState对象维护了2个变量

            pid_t               mCallingPid;

            uid_t               mCallingUid;

    从变量名称来看,这2个变量保存了进程的PID和UID,并且由于这两个变量由IPCThreadState对象维护,可见它们是与IPC相关的。具体它们保存的是IPC发送方的PID和UID还是当前进程的IPD和UID,视情况而定。

    在IPC调用过程中,被调用方需要知道调用方的UID和PID,以便被调用方用于权限检测;所以需要一种方式来提供调用方的UID和PID,因此上述2个变量的主要作用就是用于权限检测。

    那么我们想象一下,下面描述的情况下,mCallingPid和mCallingUid又应该保存谁的UID和PID?假如有2个进程process A和process B,我们站在process B的角度来分析,process A IPC调用process B, 而process B 又调用同样处于process B的Service的接口(尽管此时实际上不是远程调用,并且开发者是知道的,但是对于Binder调用机制来说,它本身并不知道当前的调用是否为远程调用,前几篇文章中有分析系统如何确定是否为远程调用,这个过程是在binder driver中实现的),那么此时mCallingPid和mCallingUid是不是应该保存process B的UID和PID?

1.       process B在被process A IPC调用时, process B需知道process A的UID和PID,来检查process A的访问权限,此时mCallingUid和mCallingPid保存的是process A的UID和PID。

2.       在IPC远程调用process B的过程中,process B的方法调用了同进程中的service的接口,process B既是调用方也是被调用方,虽然这个过程比较无聊,但是鉴于IPC过程的不透明性,因此process B仍然需要进行权限检测。

 

    前面的文章中分析过,binder driver会判断当前的Binder调用是否为远程调用,如果是同进程调用的话,BD就不会再向应用提供进程的PID和UID。因此在process B中需要显示的设置当前的PID和UID。

    为实现以上case, android提供了一组函数

    public static final native long clearCallingIdentity();

    public static final native void restoreCallingIdentity(long token);

    process B的方法调用了同进程中的service的接口前,clearCallingIdentity()方法会清除process A的UID和PID,重置为process B的UID和PID。

    process B的方法调用了同进程中的service的接口后,此时仍然处在process A远程调用process B方法的过程中,此时需要restore  process A的UID和PID。

    本文描述的case,虽然在application 开发中并不常见,但是在system_server中很常见,比如client调用ActivityManagerService的方法,而ActivityManagerService又调用了PackageManagerService的方法,并且ActivityManagerService和PackageManagerService均会运行在system_server进程中。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:66411次
    • 积分:737
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:33篇
    • 译文:0篇
    • 评论:0条
    文章分类