ClipboardService(CBS)中的权限管理

阳光穿透心脏的1/2处 2021-12-17 09:15 180阅读 0赞

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\]

这里声明了一个名为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中的权限管理。

![s11162474.jpg][]【内容简介】

本 书是“深入理解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_blog.csdn.net_Innost]

【关于本书的各种网址】

豆瓣网：[http://book.douban.com/subject/11542973/][http_book.douban.com_subject_11542973]  
互动网：[http://product.china-pub.com/3683060][http_product.china-pub.com_3683060]  
当当网：[http://product.dangdang.com/product.aspx?product\_id=22840152][http_product.dangdang.com_product.aspx_product_id_22840152]  
卓越网：[http://www.amazon.cn/dp/B008RVQMBK  
][http_www.amazon.cn_dp_B008RVQMBK]京东网：[http://book.360buy.com/11056661.html][http_book.360buy.com_11056661.html]

转载于:https://www.cnblogs.com/hzbook/archive/2012/08/06/2625292.html

[s11162474.jpg]: http://img1.douban.com/lpic/s11162474.jpg
[http_blog.csdn.net_Innost]: http://blog.csdn.net/Innost
[http_book.douban.com_subject_11542973]: http://book.douban.com/subject/11542973/
[http_product.china-pub.com_3683060]: http://product.china-pub.com/3683060
[http_product.dangdang.com_product.aspx_product_id_22840152]: http://product.dangdang.com/product.aspx?product_id=22840152
[http_www.amazon.cn_dp_B008RVQMBK]: http://www.amazon.cn/dp/B008RVQMBK
[http_book.360buy.com_11056661.html]: http://book.360buy.com/11056661.html