Android ContentProvider調用報錯"Bad call:..."及相關Binder權限問題分析

時間  2019-11-16
標籤 android contentprovider 調用 報錯 bad 相關 binder 權限 問題 分析 欄目 Android 简体版
原文   原文鏈接

問題：

項目中有一下狀況：進程A調用另外一進程的Ｂ ContentProvider,Ｂ在該這次query中須要在query另外一個 Ｃ ContentProvider:java

class BContentProvider extends ContentProvider {
        Context mContext;
        ...
        @Override
        public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
            ...
            try {
                // query C ContentProvider：
                Cursor cursor = mContext.getContentResolver().query(...);
                if (cursor != null) {
                    try {
                        //do something;
                    } finally {
                        cursor.close();
                    }
                }
                Cursor cursor = mContext.getContentResolver().query(...);
            ...
        ...
            }
        }
    }
複製代碼

在這種狀況下，系統拋出Exception以下：android

1-11 16:04:51.867  2633  3557 W AppOps  : Bad call: specified package com.providers.xxx under uid 10032 but it is really 10001
01-11 16:04:51.867  2633  3557 W AppOps  : java.lang.RuntimeException: here
01-11 16:04:51.867  2633  3557 W AppOps  : 	at com.android.server.AppOpsService.getOpsRawLocked(AppOpsService.java:1399)
01-11 16:04:51.867  2633  3557 W AppOps  : 	at com.android.server.AppOpsService.noteOperationUnchecked(AppOpsService.java:1115)
01-11 16:04:51.867  2633  3557 W AppOps  : 	at com.android.server.AppOpsService.noteProxyOperation(AppOpsService.java:1093)
01-11 16:04:51.867  2633  3557 W AppOps  : 	at com.android.internal.app.IAppOpsService$Stub.onTransact(IAppOpsService.java:157)
01-11 16:04:51.867  2633  3557 W AppOps  : 	at android.os.BinderInjector.onTransact(BinderInjector.java:30)
01-11 16:04:51.867  2633  3557 W AppOps  : 	at android.os.Binder.execTransact(Binder.java:569)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: Writing exception to parcel
01-11 16:04:51.868  4659  6791 E DatabaseUtils: java.lang.SecurityException: Proxy package com.providers.xxx from uid 10001 or calling package com.providers.xxx from uid 10032 not allowed to perform READ_PROVIDER_C
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.app.AppOpsManager.noteProxyOp(AppOpsManager.java:1834)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProvider.checkPermissionAndAppOp(ContentProvider.java:538)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:560)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:483)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProvider$Transport.query(ContentProvider.java:212)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentResolver.query(ContentResolver.java:532)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentResolver.query(ContentResolver.java:473)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at com.android.providers.xxx.BDatabaseHelper.query(BDatabaseHelper.java:7238)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProvider$Transport.query(ContentProvider.java:239)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.os.BinderInjector.onTransact(BinderInjector.java:30)
01-11 16:04:51.868  4659  6791 E DatabaseUtils: 	at android.os.Binder.execTransact(Binder.java:569)
複製代碼

分析：

因爲錯誤log首先反應了沒有C ContentProvider的權限，但檢查A應用是有C的讀寫權限的。因此排除了A的權限問題。 繼續分析： 經過log能夠看到確實是ContentProvider在作權限檢查時出錯。經過log中對應的源碼進行分析： 首先能夠看到ContentProvider.query()的時候作了權限檢查，注意，傳入的enforceReadPermission()的callingPkg是調用方的包名，以上面爲例，就是B的包名。git

ContentProvider.query():bash

@Override
        public Cursor query(String callingPkg, Uri uri, @Nullable String[] projection, @Nullable Bundle queryArgs, @Nullable ICancellationSignal cancellationSignal) {
            validateIncomingUri(uri);
            uri = maybeGetUriWithoutUserId(uri);
            if (enforceReadPermission(callingPkg, uri, null) != AppOpsManager.MODE_ALLOWED) {
複製代碼

enforceReadPermission()調用了.checkPermissionAndAppOp()方法，ContentProvider.checkPermissionAndAppOp()調用了AppOpsManager.noteProxyOp()去作檢查出了異常。app

AppOpsManager.noteProxyOp()：ide

public int noteProxyOp(int op, String proxiedPackageName) {
        int mode = noteProxyOpNoThrow(op, proxiedPackageName);
        if (mode == MODE_ERRORED) {
            throw new SecurityException("Proxy package " + mContext.getOpPackageName()
                    + " from uid " + Process.myUid() + " or calling package "
                    + proxiedPackageName + " from uid " + Binder.getCallingUid()
                    + " not allowed to perform " + sOpNames[op]);
        }
        return mode;
    }
複製代碼

noteProxyOpNoThrow()又作了什麼呢？ AppOpsManager.noteProxyOpNoThrow():ui

/** * Like {@link #noteProxyOp(int, String)} but instead * of throwing a {@link SecurityException} it returns {@link #MODE_ERRORED}. * @hide */
    public int noteProxyOpNoThrow(int op, String proxiedPackageName) {
        try {
            return mService.noteProxyOperation(op, mContext.getOpPackageName(),
                    Binder.getCallingUid(), proxiedPackageName);
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
    }
複製代碼

可見noteProxyOpNoThrow()是經過binder調用到了AppOpsService.noteProxyOperation()方法，注意，這裏傳入的是AppOpsService.noteProxyOperation()的後兩個參數爲Binder.getCallingUid()和以前層層傳入的調用方的包名，也就是上面例子的B的包名。this

下面，繼續看binder另外一側的AppOpsService.noteProxyOperation()方法,咱們結合log中AppOps的輸出log：spa

AppOpsService.noteProxyOperation():線程

@Override
    public int noteProxyOperation(int code, String proxyPackageName, int proxiedUid, String proxiedPackageName) {
        verifyIncomingOp(code);
        final int proxyUid = Binder.getCallingUid();
        String resolveProxyPackageName = resolvePackageName(proxyUid, proxyPackageName);
        if (resolveProxyPackageName == null) {
            return AppOpsManager.MODE_IGNORED;
        }
        final int proxyMode = noteOperationUnchecked(code, proxyUid,
                resolveProxyPackageName, -1, null);
        if (proxyMode != AppOpsManager.MODE_ALLOWED || Binder.getCallingUid() == proxiedUid) {
            return proxyMode;
        }
        String resolveProxiedPackageName = resolvePackageName(proxiedUid, proxiedPackageName);
        if (resolveProxiedPackageName == null) {
            return AppOpsManager.MODE_IGNORED;
        }
        return noteOperationUnchecked(code, proxiedUid, resolveProxiedPackageName,
                proxyMode, resolveProxyPackageName);
    }
複製代碼

AppOpsService.noteOperationUnchecked():

private int noteOperationUnchecked(int code, int uid, String packageName, int proxyUid, String proxyPackageName) {
        Op op = null;
        Op switchOp = null;
        int switchCode;
        int resultMode = AppOpsManager.MODE_ALLOWED;
        synchronized (this) {
            Ops ops = getOpsRawLocked(uid, packageName, true);
          ...
         }
    ...
}
複製代碼

AppOpsService.getOpsRawLocked():

private Ops getOpsRawLocked(int uid, String packageName, boolean edit) {
        ...
        Ops ops = uidState.pkgOps.get(packageName);
        if (ops == null) {
            if (!edit) {
                return null;
            }
            boolean isPrivileged = false;
            // This is the first time we have seen this package name under this uid,
            // so let's make sure it is valid.
            if (uid != 0) {
                final long ident = Binder.clearCallingIdentity();
                try {
                    int pkgUid = -1;
                    try {
                        ApplicationInfo appInfo = ActivityThread.getPackageManager()
                                .getApplicationInfo(packageName,
                                        PackageManager.MATCH_DEBUG_TRIAGED_MISSING,
                                        UserHandle.getUserId(uid));
                        if (appInfo != null) {
                            pkgUid = appInfo.uid;
                            isPrivileged = (appInfo.privateFlags
                                    & ApplicationInfo.PRIVATE_FLAG_PRIVILEGED) != 0;
                        }
                        ...
                    }
                    ...
                    if (pkgUid != uid) {
                        // Oops! The package name is not valid for the uid they are calling
                        // under. Abort.
                        RuntimeException ex = new RuntimeException("here");
                        ex.fillInStackTrace();
                        Slog.w(TAG, "Bad call: specified package " + packageName
                                + " under uid " + uid + " but it is really " + pkgUid, ex);
                        return null;
                    }
                } finally {
                    Binder.restoreCallingIdentity(ident);
                }
            }
            ops = new Ops(packageName, uidState, isPrivileged);
            uidState.pkgOps.put(packageName, ops);
        }
        return ops;
    }
複製代碼

這裏主要的操做就是將傳入的uid和包名進行判斷：比對該包對應的uid和傳入的uid比較，若是不一致就報錯。錯誤信息和log中的一致：

Bad call: specified package com.providers.xxx under uid 10032 but it is really 10001
複製代碼

上文提到了，這個包名是傳入的ContentProvider的調用方的包名，也就是例子中的B的包名。而uid是在AppOpsManager中經過Binder.getCallingUid()得到的。log中顯示，此uid並非B的uid，而是其上游調用者A的uid。 爲何在C中調用Binder.getCallingUid()獲得的是A進程的呢？我找到了袁輝輝大神的一片博客： Binder IPC的權限控制

「線程B經過Binder調用當前線程的某個組件：此時線程B是線程B某個組件的調用端，則mCallingUid和mCallingPid應該保存當前線程B的PID和UID，故須要調用clearCallingIdentity()方法完成這個功能。當線程B調用完某個組件，因爲線程B仍然處於線程A的被調用端，所以mCallingUid和mCallingPid須要恢復成線程A的UID和PID，這是調用restoreCallingIdentity()便可完成。」

Binder的機制就是這麼設計的，因此須要在B進行下一次Binder調用(也就是query ContentProvider)以前調用clearCallingIdentity()來將B的 PID和UID附給mCallingUid和mCallingPid。Binder調用結束後在restoreCallingIdentity()來將其恢復成其本來調用方的PID和UID。這樣在C裏就會用B的相關信息進行權限校驗，在AppOpsService.getOpsRawLocked()，UID和包名都是B的，是一致的，就不會報錯。

解決辦法

其實上文也已經提到了，參考 Binder IPC的權限控制，在B進行Query先後分別調用clearCallingIdentity() //做用是清空遠程調用端的uid和pid，用當前本地進程的uid和pid替代，這樣在以後的調用方去進行權限校驗時會以B的信息爲主，不會出現包名和UID不一致的狀況。 最後修改過的調用方式以下：

long token = Binder.clearCallingIdentity();
        try {
            Cursor cursor = mContext.getContentResolver().query(...);
            if (cursor != null) {
                try {
                    //do something;
                } finally {
                    cursor.close();
                }
            }
        } finally {
            Binder.restoreCallingIdentity(token);
        }
複製代碼

總結：

  1. ContentProvider是用Binder實現的，查詢的過程其實就是一次Binder調用，因此想深刻了解ContentProvider必定要會一些Binder相關的知識。

  2. ContentProvider在接受一次查詢前會調用AppOpsManager(其會經過Binder再由AppOpsService完成)進行權限校驗，其中會校驗調用方的UID和包名是否一致，其相關功能可見文章： Android 權限管理 —— AppOps。

  3. Binder調用時候能夠經過Binder.getCallingPid()和Binder.getCallingUid()來獲取調用方的PID和UID，而若是A經過Binder調用B，B又Binder調用了C，那麼在C中Binder.getCallingPid()和Binder.getCallingUid()獲得的是A的PID和UID，這種狀況下須要在B調用C的先後用Binder.clearCallingIdentity()和Binder.restoreCallingIdentity()使其帶上B的PID和UID，從而在C中進行權限校驗時候用B的信息進行校驗，固然這也符合邏輯，B調用的C，應該B須要有相應權限。

  4. Binder.clearCallingIdentity()和Binder.restoreCallingIdentity()的實現原理 Binder IPC的權限控制也有介紹，是經過移位實現的。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程