從ContentProvider報SecurityException分析出Android5.0+的一個隱藏大坑

codezjx發表於2018-04-03
IDEExceptionAndroid

前言

最近在開發A應用的時候對接了合作方的一個B應用，對方很快就把介面文件發了過來，約定好我們之間通過B應用提供的XXXContentProvider來獲取相關的資料。一切看起來是如此的普通與簡單，但是從剛開始除錯的那一刻起，詭異的事情就傳送了。九十歲老太為何起死回生？數百頭母豬為何半夜慘叫？女生宿舍為何頻頻失竊？超市方便麵為何慘招毒手？在這一切的背後，是人性的扭曲，還是道德的淪喪？事件的最後，讓我發現了Android系統的一個大坑！滴滴~ 老司機馬上開車，帶你一同踏上這段難忘的踩坑經歷~

先簡單回顧下Android的permissions機制

在AndroidManifest.xml裡面宣告ContentProvider的時候，我們是可以指定對應的readPermission與writePermission的，這樣就可以限制第三方應用程式，必須宣告指定的讀寫許可權，才能進行下一步的訪問，提高安全性。

<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/>定義好相關應用的許可權，且你可以通過android:protectionLevel來定義許可權的訪問等級。常用的有以下幾種，更多引數介紹詳見官網permission-element。

  • signature: 呼叫App必須與宣告該permission的App使用同一簽名
  • system: 系統App才能進行訪問
  • normal: 預設值，系統在安裝呼叫App的時候自動進行授權
<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?

在呼叫App中，通過<uses-permission />宣告好呼叫需要的許可權，然後通過getContentResolver().query()方法進行資料查詢，就這麼簡單兩步。這個時候，程式居然崩潰了，丟擲了SecurityException。這尼瑪我不是按照介面文件宣告好許可權了麼？怎麼會報安全問題呢？一定是我開啟的方式不對。

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所在的應用發出來的，我們都知道ContentProvider中的各種操作其實底層都是通過Binder進行程式間通訊的。如果Server發生異常，會把exception寫進reply parcel中回傳到Client，然後Client通過android.os.Parcel.readException()讀出Server的exception，然後丟擲來。沒錯，就是這麼暴力~

這個時候我開始懷疑介面文件的準確性了，馬上擼起我的jadx對目標apk進行了反編譯，查了下對方的AndroidManifest.xml檔案。裡面宣告的permission的確沒錯，而且ContentProvider的authorities屬性也是正確的，exported屬性也是true。

SecurityException再次出現

當時一下子沒細想，為了快點把資料聯調好，我們暫時把permission給去掉了。哎呀媽，心想這下子可以安心的聯調了。沒想到，詭異的事情再次發生了。程式執行，SecurityException又再次出現了，還是跟上面的Log一模一樣。這尼瑪許可權不都去掉了嗎？為什麼還報這個異常呢？

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()

仔細分析了上面這段關鍵的Log，發現requires null這個關鍵的字眼。一般在ContentProvider出現許可權問題的時候，會通過requires告訴你到底缺了什麼permission。然而這裡為什麼是null呢？想想總感覺不對勁。

Read the Fucking Source Code

合作方告知，當初一直在4.4的機器上除錯的，一直沒出現過這個問題。這次在5.1的機器上跑，才發現會奔潰。經過了各種嘗試與除錯（此處省略一萬字），還是沒能找到報錯的原因，甚至曾一度開始懷疑人生了。這個時候，只能去啃啃原始碼了，看能不能發現什麼端倪。

ContentProvider的原始碼位於frameworks/base/core/java/android/content/ContentProvider.java，沒有系統原始碼的也可以直接翻SDK的原始碼檔案。直接檢視Log中報錯的位置enforceReadPermissionInner()方法。

這段方法比較短，還是比較好理解的，其實就是在類似query()這些操作前會做一個檢查，確認呼叫方是否具有某些permission。如果沒授權，就會直接丟擲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);
}
複製程式碼

我們來關注下為什麼會是requires null，其實就是因為missingPerm沒有被賦值。再仔細分析，如果下面這大段程式碼沒有被執行的話，那麼missingPerm就不會被賦值。

if (mExported && checkUser(pid, uid, context)) {
    ......
}
複製程式碼

前面已經確認過mExported肯定是true的，那麼沒執行的原因就是checkUser()方法返回了false。（之前有提到在Android4.4是不會出現這個SecurityException的，為什麼呢？因為在Android5.0+後ContentProvider才增加了這段多使用者檢查的程式碼，淚奔~）

我們來看下checkUser()這個方法，種種跡象表明，就是因為它返回了false，導致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;
}
複製程式碼

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

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

前面在踩坑的時候，自己寫了一套測試的demo，在正常情況下UserHandle.getUserId(uid) == context.getUserId()是會返回true的，其中返回的userId都是0（因為我測試機器就一個使用者）

種種跡象表明，合作方提供的問題應用中context.getUserId()返回值並不是0。在強烈的好奇心驅使下，我又擼起了jadx對目標apk再次進行了反編譯，全域性搜尋了下getUserId()方法，發現還真TM有類似的方法，在BaseApplication中，有這麼一個getUserId()方法，用來返回註冊使用者的id。

而在ContentProvider中，mContext也就是Application這個Context例項，也就是說getUserId()方法被無意識的進行了重寫。因此，解決這個SecurityException異常最簡單的方法就是把BaseApplication中的getUserId()方法換個名字就好了。至此，整個踩坑經歷終於到了尾聲。

總結

通過這次踩坑，發現了Android系統中一個隱藏的問題。在自定義的Application中，如果你宣告瞭public int getUserId()這個方法，並且返回的不是當前使用者的userId，那麼你的ContentProvider在Android5.0+的機器都會失效。不信？自己試試~

/** @hide */
@Override
public int getUserId() {
    return mBase.getUserId();
}
複製程式碼

因為這個是一個@hide方法，所以通常這個重寫行為都是無意識的，IDE並不會提示你重寫了Application中的這個方法。但如果你比較幸運，剛好用了帶hidden-api的Android SDK Jar包，那麼IDE會給你一個提示，但除了系統應用開發，一般很少人會匯入hidden-api吧~

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

好了，這次的分析先到這裡，希望大家以後遇到這個詭異的SecurityException異常的時候，不至於再跳進這個隱藏的大坑裡~ Over~

點選此處閱讀原文：codezjx.github.io/2018/03/30/…

相關文章