前言

最近在開發(fā)A應(yīng)用的時(shí)候?qū)恿撕献鞣降囊粋€(gè)B應(yīng)用，對(duì)方很快就把接口文檔發(fā)了過來，約定好我們之間通過B應(yīng)用提供的XXXContentProvider來獲取相關(guān)的數(shù)據(jù)巡蘸。一切看起來是如此的普通與簡(jiǎn)單畅蹂，但是從剛開始調(diào)試的那一刻起，詭異的事情就發(fā)送了撞蜂。九十歲老太為何起死回生？數(shù)百頭母豬為何半夜慘叫侥袜？女生宿舍為何頻頻失竊蝌诡？超市方便面為何慘招毒手？在這一切的背后枫吧，是人性的扭曲浦旱，還是道德的淪喪？事件的最后九杂，讓我發(fā)現(xiàn)了Android系統(tǒng)的一個(gè)大坑颁湖！滴滴~ 老司機(jī)馬上開車，帶你一同踏上這段難忘的踩坑經(jīng)歷~

先簡(jiǎn)單回顧下Android的permissions機(jī)制

在AndroidManifest.xml里面聲明ContentProvider的時(shí)候例隆，我們是可以指定對(duì)應(yīng)的readPermission與writePermission的甥捺，這樣就可以限制第三方應(yīng)用程序，必須聲明指定的讀寫權(quán)限镀层，才能進(jìn)行下一步的訪問镰禾，提高安全性。

<provider
    android:name=".provider.XXXContentProvider"
    android:authorities="com.aaa.bbb.ccc.provider.authorities"
    android:readPermission="com.aaa.bbb.ccc.provider.permission.READ_PERM"
    android:writePermission="com.aaa.bbb.ccc.provider.permission.WRITE_PERM"
    android:exported="true"/>

但是首先唱逢，我們得先通過<permission/>定義好相關(guān)應(yīng)用的權(quán)限吴侦，且你可以通過android:protectionLevel來定義權(quán)限的訪問等級(jí)。常用的有以下幾種坞古，更多參數(shù)介紹詳見官網(wǎng)permission-element备韧。

• signature: 調(diào)用App必須與聲明該permission的App使用同一簽名
• system: 系統(tǒng)App才能進(jìn)行訪問
• normal: 默認(rèn)值，系統(tǒng)在安裝調(diào)用App的時(shí)候自動(dòng)進(jìn)行授權(quán)

<permission
    android:name="com.aaa.bbb.ccc.provider.permission.READ_PERM"
    android:protectionLevel="normal" />
<permission
    android:name="com.aaa.bbb.ccc.provider.permission.WRITE_PERM"
    android:protectionLevel="normal" />

What the fuck? SecurityException?

在調(diào)用App中痪枫，通過<uses-permission />聲明好調(diào)用需要的權(quán)限织堂，然后通過getContentResolver().query()方法進(jìn)行數(shù)據(jù)查詢叠艳，就這么簡(jiǎn)單兩步。這個(gè)時(shí)候易阳，程序居然崩潰了虑绵，拋出了SecurityException。這尼瑪我不是按照接口文檔聲明好權(quán)限了么闽烙？怎么會(huì)報(bào)安全問題呢翅睛？一定是我打開的方式不對(duì)。

03-29 12:08:12.839 4255-4271/com.codezjx.provider E/DatabaseUtils: Writing exception to parcel
    java.lang.SecurityException: Permission Denial: reading com.aaa.bbb.ccc.XXXProvider uri content://com.aaa.bbb.ccc.xxx/getxxx/ from pid=22529, uid=10054 requires null, or grantUriPermission()
        at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:539)
        at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:452)
        at android.content.ContentProvider$Transport.query(ContentProvider.java:205)
        at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
        at android.os.Binder.execTransact(Binder.java:500)

上面這段Log是在ContentProvider所在的應(yīng)用發(fā)出來的黑竞，我們都知道ContentProvider中的各種操作其實(shí)底層都是通過Binder進(jìn)行進(jìn)程間通信的捕发。如果Server發(fā)生異常，會(huì)把exception寫進(jìn)reply parcel中回傳到Client很魂，然后Client通過android.os.Parcel.readException()讀出Server的exception扎酷，然后拋出來。沒錯(cuò)遏匆，就是這么暴力~

這個(gè)時(shí)候我開始懷疑接口文檔的準(zhǔn)確性了法挨，馬上擼起我的jadx對(duì)目標(biāo)apk進(jìn)行了反編譯，查了下對(duì)方的AndroidManifest.xml文件幅聘。里面聲明的permission的確沒錯(cuò)凡纳，而且ContentProvider的authorities屬性也是正確的，exported屬性也是true帝蒿。

SecurityException再次出現(xiàn)

當(dāng)時(shí)一下子沒細(xì)想荐糜，為了快點(diǎn)把數(shù)據(jù)聯(lián)調(diào)好，我們暫時(shí)把permission給去掉了葛超。哎呀媽暴氏，心想這下子可以安心的聯(lián)調(diào)了。沒想到绣张，詭異的事情再次發(fā)生了答渔。程序運(yùn)行，SecurityException又再次出現(xiàn)了侥涵，還是跟上面的Log一模一樣沼撕。這尼瑪權(quán)限不都去掉了嗎？為什么還報(bào)這個(gè)異常呢独令？

java.lang.SecurityException: Permission Denial: reading com.aaa.bbb.ccc.XXXProvider uri content://com.aaa.bbb.ccc.xxx/getxxx/ from pid=22529, uid=10054 requires null, or grantUriPermission()

仔細(xì)分析了上面這段關(guān)鍵的Log端朵，發(fā)現(xiàn)requires null這個(gè)關(guān)鍵的字眼好芭。一般在ContentProvider出現(xiàn)權(quán)限問題的時(shí)候燃箭，會(huì)通過requires告訴你到底缺了什么permission。然而這里為什么是null呢舍败？想想總感覺不對(duì)勁招狸。

Read the Fucking Source Code

合作方告知敬拓，當(dāng)初一直在4.4的機(jī)器上調(diào)試的，一直沒出現(xiàn)過這個(gè)問題裙戏。這次在5.1的機(jī)器上跑乘凸，才發(fā)現(xiàn)會(huì)奔潰。經(jīng)過了各種嘗試與調(diào)試（此處省略一萬字）累榜，還是沒能找到報(bào)錯(cuò)的原因营勤，甚至曾一度開始懷疑人生了。這個(gè)時(shí)候壹罚，只能去啃啃源碼了葛作，看能不能發(fā)現(xiàn)什么端倪。

ContentProvider的源碼位于frameworks/base/core/java/android/content/ContentProvider.java猖凛，沒有系統(tǒng)源碼的也可以直接翻SDK的源碼文件赂蠢。直接查看Log中報(bào)錯(cuò)的位置enforceReadPermissionInner()方法。

這段方法比較短辨泳，還是比較好理解的虱岂，其實(shí)就是在類似query()這些操作前會(huì)做一個(gè)檢查，確認(rèn)調(diào)用方是否具有某些permission菠红。如果沒授權(quán)第岖，就會(huì)直接拋出SecurityException。

/** {@hide} */
protected void enforceReadPermissionInner(Uri uri, IBinder callerToken)
        throws SecurityException {
    final Context context = getContext();
    final int pid = Binder.getCallingPid();
    final int uid = Binder.getCallingUid();
    String missingPerm = null;

    if (UserHandle.isSameApp(uid, mMyUid)) {
        return;
    }

    if (mExported && checkUser(pid, uid, context)) {
        final String componentPerm = getReadPermission();
        if (componentPerm != null) {
            if (context.checkPermission(componentPerm, pid, uid, callerToken)
                    == PERMISSION_GRANTED) {
                return;
            } else {
                missingPerm = componentPerm;
            }
        }

        // track if unprotected read is allowed; any denied
        // <path-permission> below removes this ability
        boolean allowDefaultRead = (componentPerm == null);

        final PathPermission[] pps = getPathPermissions();
        if (pps != null) {
            final String path = uri.getPath();
            for (PathPermission pp : pps) {
                final String pathPerm = pp.getReadPermission();
                if (pathPerm != null && pp.match(path)) {
                    if (context.checkPermission(pathPerm, pid, uid, callerToken)
                            == PERMISSION_GRANTED) {
                        return;
                    } else {
                        // any denied <path-permission> means we lose
                        // default <provider> access.
                        allowDefaultRead = false;
                        missingPerm = pathPerm;
                    }
                }
            }
        }

        // if we passed <path-permission> checks above, and no default
        // <provider> permission, then allow access.
        if (allowDefaultRead) return;
    }

    // last chance, check against any uri grants
    final int callingUserId = UserHandle.getUserId(uid);
    final Uri userUri = (mSingleUser && !UserHandle.isSameUser(mMyUid, uid))
            ? maybeAddUserId(uri, callingUserId) : uri;
    if (context.checkUriPermission(userUri, pid, uid, Intent.FLAG_GRANT_READ_URI_PERMISSION,
            callerToken) == PERMISSION_GRANTED) {
        return;
    }

    final String failReason = mExported
            ? " requires " + missingPerm + ", or grantUriPermission()"
            : " requires the provider be exported, or grantUriPermission()";
    throw new SecurityException("Permission Denial: reading "
            + ContentProvider.this.getClass().getName() + " uri " + uri + " from pid=" + pid
            + ", uid=" + uid + failReason);
}

我們來關(guān)注下為什么會(huì)是requires null试溯，其實(shí)就是因?yàn)?code>missingPerm沒有被賦值绍傲。再仔細(xì)分析，如果下面這大段代碼沒有被執(zhí)行的話耍共，那么missingPerm就不會(huì)被賦值烫饼。

if (mExported && checkUser(pid, uid, context)) {
    ......
}

前面已經(jīng)確認(rèn)過mExported肯定是true的，那么沒執(zhí)行的原因就是checkUser()方法返回了false试读。（之前有提到在Android4.4是不會(huì)出現(xiàn)這個(gè)SecurityException的杠纵，為什么呢？因?yàn)樵贏ndroid5.0+后ContentProvider才增加了這段多用戶檢查的代碼钩骇，淚奔~）

我們來看下checkUser()這個(gè)方法比藻，種種跡象表明，就是因?yàn)樗祷亓薴alse倘屹，導(dǎo)致missingPerm沒賦值银亲，并最終throw了SecurityException。

boolean checkUser(int pid, int uid, Context context) {
    return UserHandle.getUserId(uid) == context.getUserId()
            || mSingleUser
            || context.checkPermission(INTERACT_ACROSS_USERS, pid, uid)
            == PERMISSION_GRANTED;
}

通過反射與其他方式纽匙，我們可以逐個(gè)驗(yàn)證checkUser()方法中各個(gè)boolean條件的值：

• (UserHandle.getUserId(uid) == context.getUserId()) -> false
• mSingleUser -> false
• (context.checkPermission(INTERACT_ACROSS_USERS, pid, uid) == PERMISSION_GRANTED) -> false

前面在踩坑的時(shí)候务蝠，自己寫了一套測(cè)試的demo，在正常情況下UserHandle.getUserId(uid) == context.getUserId()是會(huì)返回true的烛缔，其中返回的userId都是0（因?yàn)槲覝y(cè)試機(jī)器就一個(gè)用戶）

種種跡象表明馏段，合作方提供的問題應(yīng)用中context.getUserId()返回值并不是0轩拨。在強(qiáng)烈的好奇心驅(qū)使下，我又?jǐn)]起了jadx對(duì)目標(biāo)apk再次進(jìn)行了反編譯院喜，全局搜索了下getUserId()方法亡蓉，發(fā)現(xiàn)還真TM有類似的方法，在BaseApplication中喷舀，有這么一個(gè)getUserId()方法砍濒，用來返回注冊(cè)用戶的id。

而在ContentProvider中硫麻，mContext也就是Application這個(gè)Context實(shí)例梯影，也就是說getUserId()方法被無意識(shí)的進(jìn)行了重寫。因此庶香，解決這個(gè)SecurityException異常最簡(jiǎn)單的方法就是把BaseApplication中的getUserId()方法換個(gè)名字就好了甲棍。至此，整個(gè)踩坑經(jīng)歷終于到了尾聲赶掖。

總結(jié)

通過這次踩坑感猛，發(fā)現(xiàn)了Android系統(tǒng)中一個(gè)隱藏的問題。在自定義的Application中奢赂，如果你聲明了public int getUserId()這個(gè)方法陪白，并且返回的不是當(dāng)前用戶的userId，那么你的ContentProvider在Android5.0+的機(jī)器都會(huì)失效膳灶。不信咱士？自己試試~

/** @hide */
@Override
public int getUserId() {
    return mBase.getUserId();
}

因?yàn)檫@個(gè)是一個(gè)@hide方法，所以通常這個(gè)重寫行為都是無意識(shí)的轧钓，IDE并不會(huì)提示你重寫了Application中的這個(gè)方法序厉。但如果你比較幸運(yùn)，剛好用了帶hidden-api的Android SDK Jar包毕箍，那么IDE會(huì)給你一個(gè)提示弛房，但除了系統(tǒng)應(yīng)用開發(fā)，一般很少人會(huì)導(dǎo)入hidden-api吧~

Missing `@Override` annotation on `getUserId()` more...

好了而柑，這次的分析先到這里文捶，希望大家以后遇到這個(gè)詭異的SecurityException異常的時(shí)候，不至于再跳進(jìn)這個(gè)隱藏的大坑里~ Over~