ClipboardService(CBS)中的权限管理

ClipboardService（CBS）是Android系统中的元老级服务了，自Android 1.0起就支持剪贴功能。在Android 4.0中再遇见它时，此功能已有了长足改进。本节将集中讨论CBS中的权限管理。先来回顾一下CBS中和权限管理相关的函数调用。

// copy方设置ClipData在CBS的setPrimaryClip函数中进行：
checkDataOwnerLocked(clip, Binder.getCallingUid());
clearActiveOwnersLocked();
// paste方获取ClipData在CBS的getPrimaryClip函数中进行：
addActiveOwnerLocked(Binder.getCallingUid(), pkg);

在分析这3个函数之前，先介绍一下Android系统中的URI权限管理。

1. URI权限管理介绍Android系统的权限管理中有一类是专门针对URI的，先来看一个示例，该例来自package/providers/ContactsProvider，在它的AndroidManifest.xml中有如下声明：

[-->AndroidManifest.xml]

<provider android:name="ContactsProvider2"
         ......
          android:readPermission="android.permission.READ_CONTACTS"
          android:writePermission="android.permission.WRITE_CONTACTS">
          ......
          <grant-uri-permission android:pathPattern=".*" />
</provider>

这里声明了一个名为ContactsProvider2的ContentProvider，并定义了几个权限声明，下面对其进行解释。

• readPermission：要求调用query函数的客户端必须声明一个use-permission为READ_CONTACTS的权限。
• writePermission：要求调用update或insert函数的客户端必须声明一个use-permission为WRITE_CONTACTS的权限。
• grant-uri-permission：和授权有关。

writePermission：要求调用update或insert函数的客户端必须声明一个use-permission为WRITE_CONTACTS的权限。grant-uri-permission：和授权有关。

初识grant-uri-permission时，会觉得它比较难理解，下面通过举例分析帮助读者加深认识。

• Contacts 和ContactProvider这两个APP都是由系统提供的程序，而且二者关系紧密，所以Contacts一定会声明use_Permission为 READ_CONTACTS和WRITE_CONTACT的权限。如此，Contacts就可以毫无阻碍地通过ContactsProvider来查询或 更新数据库了。
• 假设Contacts新增一个功能，将ContactsProvider中的某条数据复制到剪切板。根据前面已介绍过的知识可以知道，Contacts会向剪切板中复制一个URI类型的数据。
• 另外一个程序从剪切板中粘贴（paste）这条数据，由于是URI类型的，所以此程序会通过ContentResolver来查询该uri所指向的数据。但是这个程序却并未声明READ_CONTACTS的权限，所以它查询数据时必然会失败。

假设Contacts新增一个功能，将ContactsProvider中的某条数据复制到剪切板。根据前面已介绍过的知识可以知道，Contacts会向剪切板中复制一个URI类型的数据。另外一个程序从剪切板中粘贴（paste）这条数据，由于是URI类型的，所以此程序会通过ContentResolver来查询该uri所指向的数据。但是这个程序却并未声明READ_CONTACTS的权限，所以它查询数据时必然会失败。

或许有人会问，为什么第三个程序不声明相应权限呢？原因很简单，第三个程序不知道自己该声明怎样的权限（除非这两个程序的开发者能互通信息）。本例 ContactsProvider设置的读权限是READ_CONTACTS，以后可能换成READ_CONTACTS_EXTEND，第三个程序不太可 能知道其中的变化。为了解决类似问题，Android提供了一套专门针对uri的权限管理机制。以这套机制解决示例中权限声明问题的方法是这样的：当第三 个程序从剪切板中粘贴数据时，系统会判断是否需要为这个程序授权。当然，系统不会随意授权，而是需要考虑ContactsProvider的情况。因为 ContactsProvider声明了grant-uri-permission，所以只要第三个程序所粘贴的URI匹配其中的 pathPattern，授权就能成功。倘若ContactsProvider没有声明grant-uri-permission，或者uri不匹配指定 的pathPattern，则授权失败。

有了前面介绍的权限管理机制，相信下面CBS中的权限管理理解起来就比较简单了。

提示　感兴趣的读者可阅读SDK安装目录下/docs/guide/topics/security/security.html中关于uri Permission的说明部分。

2. checkDataOwnerLocked函数分析

checkDataOwnerLocked函数的代码如下：

[-->ClipboardService.java::checkDataDwnerLocked]

 

private  final  void checkDataOwnerLocked(ClipData data,  int uid) {
       // 第二个参数uid为copy方进程的uid
       final  int N = data.getItemCount();
       for ( int i=0; i<N; i++) {
           // 为每一个item调用checkItemOwnerLocked
          checkItemOwnerLocked(data.getItemAt(i), uid);
      }
}
//  checkItemOwnerLocked函数分析
private  final  void checkItemOwnerLocked(ClipData.Item item,  int uid) {
       if (item.getUri() !=  null) { // 检查uri
          checkUriOwnerLocked(item.getUri(), uid);
      }
      Intent intent = item.getIntent();
       // getData函数返回的也是一个uri，因此这里实际上检查的也是uri
       if (intent !=  null && intent.getData() !=  null) {
          checkUriOwnerLocked(intent.getData(), uid);
      }
}

 

权限检查就是针对uri的，因为uri所指向的数据可能是系统内部使用或私密的。例如Setting数据中的Secure表，这里的数据不 能随意访问。虽然直接使用ContentResolver访问这些数据时系统会进行权限检查，但是由于目前的剪切板服务也支持URI数据类型，所以这里也 需要做检查，否则恶意程序就能轻松读取私密信息。
下边来分析checkUriOwnerLocked函数，其代码如下：

[-->ClipboardService.java::checkUriOwnerLocked]

private  final  void checkUriOwnerLocked(Uri uri,  int uid) {
      ......
       long ident = Binder.clearCallingIdentity();
       boolean allowed =  false;
       try {
           /*
            调用ActivityManagerService的checkGrantUriPermission函数，
             该函数内部将检查copy方是否能被赋予URI_READ权限。如果不允许，
             该函数会抛SecurityException异常
           */
          mAm.checkGrantUriPermission(uid,  null, uri, 
                                         Intent.FLAG_GRANT_READ_URI_PERMISSION);
      }  catch (RemoteException e) {
      }  finally {
          Binder.restoreCallingIdentity(ident);
      }
  }

根据前面的知识，这里先要检查copy方是否有读取uri的权限。下面来分析paste方的权限管理。

3. clearActiveOwnersLocked函数分析

clearActiveOwnersLocked函数的代码如下：

[-->ClipboardService.java::clearActiveOwnersLocked]

private  final  void addActiveOwnerLocked( int uid, String pkg) {
      PackageInfo pi;
       try {
          /*
         调用PackageManagerService的getPackageInfo函数得到相关信息
          然后做一次安全检查，如果PacakgeInfo的uid信息和当前调用的uid不一致，
          则抛出SecurityException。这个很好理解，因为paste方可以传递虚假的
          packagename，但uid是没法造假的
           */
          pi = mPm.getPackageInfo(pkg, 0); 
           if (pi.applicationInfo.uid != uid) {
               throw  new SecurityException("Calling uid " + uid
                      + " does not own package " + pkg);
          }
       } ......
      }
       // mActivePermissionOwners用来保存已经通过安全检查的package
       if (mPrimaryClip !=  null && !mActivePermissionOwners.contains(pkg)) {
           // 针对ClipData中的每一个Item，都需要调用grantItemLocked来检查权限
           final  int N = mPrimaryClip.getItemCount();
           for ( int i=0; i<N; i++) {
              grantItemLocked(mPrimaryClip.getItemAt(i), pkg);
          } // 保存package信息到mActivePermissionOwners
          mActivePermissionOwners.add(pkg);
      }
}
// grantItemLocked分析
private  final  void grantItemLocked(ClipData.Item item, String pkg) {
       if (item.getUri() !=  null) {
          grantUriLocked(item.getUri(), pkg);
      }  // 和copy方一样，这里仅检查uri的情况
      Intent intent = item.getIntent();
       if (intent !=  null && intent.getData() !=  null) {
          grantUriLocked(intent.getData(), pkg);
      }
}

再来看grantUriLocked的代码：

[-->ClipboardService.java::grantUriLocked]

private  final  void grantUriLocked(Uri uri, String pkg) {
       long ident = Binder.clearCallingIdentity();
       try {
          /*
             调用ActivityManagerService的grantUriPermissionFromOwner函数，
             注意第二个参数传递的是CBS所在进程的uid。该函数内部也会检查权限。
              该函数调用成功后，paste方就被授予了对应uri的读权限
           */
          mAm.grantUriPermissionFromOwner(mPermissionOwner, 
                                  Process.myUid(), pkg, uri,
                                  Intent.FLAG_GRANT_READ_URI_PERMISSION);
      }  catch (RemoteException e) {
      }  finally {
          Binder.restoreCallingIdentity(ident);
      }
}

既然有授权，那么客户端使用完毕后就需要撤销授权，这个工作是在setPrimaryClip函数的 clearActiveOwnersLocked中完成的。当为剪切板设置新的ClipData时，自然需要将与旧ClipData相关的权限撤销。读者 可自行分析clearActiveOwnersLocked函数。
------------------------------

本文节选自《深入理解Android：卷II》第3章“深入理解SystemServer”第3.7.3节：CBS中的权限管理。

【内容简介】

本 书是“深入理解Android”系列的第二本，第一本书上市后得到了广大读者的高度评价，在Android开发者社群内口口相传。本书不仅继承了第一本的 优点、改正了其在细微处存在的一些不足，而且还在写作的总体思想上进行了创新，更强调从系统设计者的角度去分析Android系统中各个模块内部的实现原 理和工作机制。从具体内容上讲，本书的重点是Android Framework的Java层，对Java层涉及的核心模块和服务进行了深入而细致的分析。通过本书，读者不仅能对Android系统本身有更深入的理 解，而且还能掌握分析大型复杂源代码的能力。

全书共8章：第1章介绍了阅读本书所需要做的准备工作，包括Android 4.0源码的下载和编译、Eclipse环境的搭建，以及Android系统进程（system_process）的调试等；第2章对Java Binder和MessageQueue的实现进行了深入分析；第3章详细剖析了SystemServer的工作原理，这些服务包括 EntropyService、DropboxManagerService、DiskStatsService、 DeviceStorageMonitorService、SamplingProfilerService和ClipboardService；第4章 对系统中负责Package信息查询和APK安装、卸载、更新等工作的服务PackageManagerService进行了详细分析；第5章则对 Android系统中负责电源管理的核心服务 PowerManagerService的原理进行了一番深入的分析；第6章以ActivityManagerService为分析重点，对它的启动、 Activity的创建和启动、BroadcastReceiver的工作原理、Android中的进程管理等内容展开了较为深入的研究；第7章对 ContentProvider的创建和启动、SQLite、Cursor query和close的实现等进行了深入分析；第8章以ContentService和AccountManagerService为分析对象，介绍了 数据更新通知机制的实现，以及账户管理和数据同步等相关知识。

【作者简介】

邓凡平，资深Android开发工程师和系统工程 师，热衷于Android源代码的研究，对Android的架构设计和实现原理有非常深刻的认识和理解，应用开发经验也十分丰富。《深入理解 Android：卷I》的作者，同时也是“深入理解Andriod”系列图书的总策划。目前就职于国内领先的Android企业中科创达 （ThunderSoft），负责Android Framework的开发和维护。喜欢钻研，乐于分享，活跃于CSDN、51CTO和开源中国等专业技术社区，撰写的Android Framework源码分析的系列文章深受读者欢迎。此外，他对Linux内核、C/C++/Python相关的技术，以及高性能网络服务器和多核并行开 发等也有一定的研究。

作者博客：http://blog.csdn.net/Innost

【关于本书的各种网址】

豆瓣网：http://book.douban.com/subject/11542973/
互动网：http://product.china-pub.com/3683060
当当网：http://product.dangdang.com/product.aspx?product_id=22840152
卓越网：http://www.amazon.cn/dp/B008RVQMBK
京东网：http://book.360buy.com/11056661.html