關於Binder中clearCallingIdentity()與restoreCallingIdentity()的作用及如何實現權限認證

鏈接：https://www.zhihu.com/question/41003297/answer/89328987， 這文章寫的很詳細， mark下

一、源碼分析

（1）clearCallingIdentity方法，最終調用如下：

int64_t IPCThreadState::clearCallingIdentity()
{
    int64_t token = ((int64_t)mCallingUid<<32) | mCallingPid;
    clearCaller();
    return token;
}

void IPCThreadState::clearCaller()
{
    mCallingPid = getpid(); //當前進程pid賦值給mCallingPid
    mCallingUid = getuid(); //當前進程uid賦值給mCallingUid
}

• mCallingUid(記爲UID)，保存Binder IPC通信的調用方進程的Uid；
• mCallingPid(記爲PID)，保存Binder IPC通信的調用方進程的Pid；

UID和PID是IPCThreadState的成員變量， 都是32位的int型數據，通過移位操作，將UID和PID的信息保存到token，其中高32位保存UID，低32位保存PID。然後調用clearCaller()方法將當前本地進程pid和uid分別賦值給PID和UID，最後返回token。

一句話總結：clearCallingIdentity作用是清空遠程調用端的uid和pid，用當前本地進程的uid和pid替代；

（2）restoreCallingIdentity方法，最終調用如下：

void IPCThreadState::restoreCallingIdentity(int64_t token)
{
    mCallingUid = (int)(token>>32);
    mCallingPid = (int)token;
}

從token中解析出PID和UID，並賦值給相應的變量。該方法正好是clearCallingIdentity的反過程。

一句話總結：restoreCallingIdentity作用是恢復遠程調用端的uid和pid信息，正好是clearCallingIdentity的反過程;

到此，應該明白了從代碼角度是如何實現的。

（3） 源碼示例
 

上述過程主要在system_server進程的各個線程中比較常見（普通的app應用很少出現），比如system_server進程中的ActivityManagerService子線程，代碼如下：

[–>ActivityManagerService.java]

 

@Override
public final void attachApplication(IApplicationThread thread) {
    synchronized (this) {
        //獲取遠程Binder調用端的pid
        int callingPid = Binder.getCallingPid();
        //清除遠程Binder調用端uid和pid信息，並保存到origId變量
        final long origId = Binder.clearCallingIdentity();
        attachApplicationLocked(thread, callingPid);
        //通過origId變量，還原遠程Binder調用端的uid和pid信息
        Binder.restoreCallingIdentity(origId);
    }
}

 

文章startService中有講到attachApplication()的調用。該方法一般是system_server進程的子線程調用遠程進程時使用，而attachApplicationLocked方法則是在同一個線程中，故需要在調用該方法前清空遠程調用者的uid和pid，調用結束後恢復遠程調用者的uid和pid。

 

二、場景分析

場景1：首先線程A通過Binder遠程調用線程B，然後線程B通過Binder調用當前線程的另一個service或者activity之類的組件

分析：

1. 線程A通過Binder遠程調用線程B：則線程B的IPCThreadState中的mCallingUid和mCallingPid保存的就是線程A的UID和PID。這時在線程B中調用Binder.getCallingPid()和Binder.getCallingUid()方法便可獲取線程A的UID和PID，然後利用UID和PID進行權限比對，判斷線程A是否有權限調用線程B的某個方法。
2. 線程B通過Binder調用當前線程的某個組件：此時線程B是線程B某個組件的調用端，則mCallingUid和mCallingPid應該保存當前線程B的PID和UID，故需要調用clearCallingIdentity()方法完成這個功能。當線程B調用完某個組件，由於線程B仍然處於線程A的被調用端，因此mCallingUid和mCallingPid需要恢復成線程A的UID和PID，這是調用restoreCallingIdentity()即可完成。

 

一句話：圖中過程2（調用組件2開始之前）執行clearCallingIdentity()，過程3（調用組件2結束之後）執行restoreCallingIdentity()。

二、類比分析
 

看完場景分析，估計還有不少朋友感到迷惑，爲何需要這兩個方法來多此一舉，直接檢測最初調用端的權限不就行了嗎？爲了更加形象明瞭地說明其用途，下面用一個生活中的場景來類比說明。

場景：假如你的朋友請你幫忙，給她(他)到你的公司以內部價購買公司的某個產品。

 

分析：這個過程分爲兩個階段

 

• 第一階段：你的朋友請你幫忙的過程，這個過程並不一定所有朋友都會幫的，這時就需要一個權限檢測，那麼在你的朋友”遠程調用”你執行任務時，你會記錄他的”Identity”信息（比如是性別），有了信息那麼就可以權限檢測，不妨令權限規則是如果這個朋友是女性則答應幫忙，否則就認定權限不夠拒絕執行（可能黑客會想到先去一趟泰國，權限控制可能相應需要打補丁了），若答應幫忙則進入第二階段，否則直接返回。
• 第二階段：你向自己所在公司的相關部門內購產品的過程，這個過程也並不是所有人都能權限能夠內購的，只有自己公司的員工才行，否則你的朋友也不會找你幫忙了。 這個過程同樣需要權限檢測，但是”Identity”保存的是性別女的信息，公司內購產品如果也以性別來判斷，那豈不是公司的所有男員工沒有權限內購，那這公司就有點太坑了，這明顯不符合實情。 clearCallingIdentity()是時候該登場了，在第二階段開始之前，先執行clearCallingIdentity()過程，也就是把”Identity”信息清空，替換爲你的信息（比如員工編碼ITCode之類的），那公司相關部門通過ITCode就可以直接判斷是否允許內購某產品。當第二階段完成後，也就是你已經購買到了公司產品，這時你需要將產品交付給你的朋友，需要restoreCallingIdentity，恢復”Identity”爲女的信息，這樣就該順便交付給你的女朋友。如果不恢復信息，還是原來的ITCode，你交付的朋友可能是男的，另有其人，這樣就不科學了。

相信到此，大都能明白這兩個方法的作用，缺一不可，而且要成對出現。