Android ContentProvider调用报错"Bad call: specified package xxx under uid 10032 but it is really 10001"及Binder权限问题分析

问题:

项目中有一下情况:进程A调用另一进程的B ContentProvider,B在该此次query中需要在query另一个 C ContentProvider:

    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如下:

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的包名。

ContentProvider.query():

        @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()去做检查出了异常。

AppOpsManager.noteProxyOp():

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

    /**
     * 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的包名。

下面,继续看binder另一侧的AppOpsService.noteProxyOperation()方法,我们结合log中AppOps的输出log:

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
2.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需要有相应权限。
3.Binder.clearCallingIdentity()和Binder.restoreCallingIdentity()的实现原理 Binder IPC的权限控制也有介绍,是通过移位实现的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 143,396评论 1 301
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,482评论 1 258
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 94,858评论 0 213
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 41,131评论 0 179
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,903评论 1 256
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,847评论 1 177
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,454评论 2 273
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,206评论 0 167
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 29,047评论 6 232
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,563评论 0 213
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,344评论 2 215
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,667评论 1 231
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,264评论 0 32
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,163评论 2 214
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,546评论 3 207
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,630评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,032评论 0 166
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,572评论 2 231
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,668评论 2 232