Android安全模型基于Linux的权限管理,使用沙箱隔离机制将每个应用的进程资源隔离。Android应用程序在安装时赋予一个UID,UID不同的应用程序完全隔离。
另一方面,应用如果想使用某种服务,需要在AndroidManifest.xml中申请。比如,想使用网络的话,需要在AndroidManifest.xml中添加:

INTERNET权限将被映射到底层的GID。所以,一个应用有一个UID,可以有多个GID,来获得多个权限。
关于Android权限管理更详细的内容这里就不再赘述了,这方面的资料很多。直接进入正题,如何自定义一个类似于上面的INTERNET的系统级权限组?
我们知道,Android本身支持在应用程序的AndroidManifest.xml中自定义权限,但这种自定义的权限没有被映射到系统底层的用户组中,没有独立的GID。如果在系统中有一个C语言写的服务,只有应用申请了权限才可以使用,我们就需要将这个权限映射到底层。

本文中,作为例子,我们假设有一个C语言实现的功能,它提供say_hello的服务,使用这个服务的应用要在AndroidManifest.xml中添加来申请权限。
AndroidManifest.xml是在安装应用的时候解析的。最终调用的解析函数是

frameworks/base/core/java/android/content/pm/PackageParser.java

针对不同标签调用对应的解析函数。对于uses-permission调用的是parseUsesPermission:

frameworks/base/core/java/android/content/pm/PackageParser.java

它的工作就是调用pkg.requestedPermissions.add(name.intern());将诸如android.permission.INTERNET这样的字符串添加到pkg.requestedPermissions列表中。
解析完成后,会调用grantPermissionsLPw获取相应的GID:

frameworks/base/services/java/com/android/server/pm/PackageManagerService.java

需要注意的是final BasePermission bp = mSettings.mPermissions.get(name);
mSettings保存了与设定相关的东西,class Settings定义在frameworks/base/services/java/com/android/server/pm/Settings.java中,它的mPermissions成员的类型是HashMap,保存了权限名字到权限信息的映射。BasePermission中有一个int[] gids成员,这就是这个权限对应的gid;还有一个PackageSettingBase类型的packageSetting成员,它指定了声明这个权限的包的配置信息。

那么,mSettings.mPermissions是在什么时候初始化的呢?
PackageManagerService在初始化时,会调用readPermissions();它又调用了readPermissionsFromXml(permFile),permFile文件的文件路径是/etc/permissions/platform.xml,这个文件中定义了底层GID和高层权限名字之间的对应关系:

frameworks/base/data/etc/platform.xml

所以我们在这个文件中添加say_hello权限:

回到readPermissionsFromXml函数,对于名字是“permission”的标签,会调用readPermission函数:

frameworks/base/services/java/com/android/server/pm/PackageManagerService.java

首先将权限的名字添加到mSettings.mPermissions列表中,然后进入while循环,把这个权限对应的所有gid都添加到bp.gids中。gid是调用Process.getGidForName根据gid的名字得到了,在我们的例子中,也就是”say_hello”。getGidForName是Process中的一个native方法:

frameworks/base/core/java/android/os/Process.java

它的实际定义是

frameworks/base/core/jni/android_util_Process.cpp

它就是根据组名调用getgrnam获取组信息。我们知道,getgrnam是一个C库函数,在Linux中标准定义是根据读取/etc/group文件获取组信息,但在Android中并没有这个文件,那么这个函数是怎么实现的呢?

bionic/libc/bionic/stubs.cpp

显而易见,它是遍历android_ids数组,查找是否有对应的组。
android_ids的定义在android_filesystem_config.h中

system/core/include/private/android_filesystem_config.h

这样就把inet字符串和整型值3003关联起来了。所以我们不妨把say_hello的整型gid定义为8001,在android_filesystem_config.h中添加

在android_ids数组中添加

这样就把字符串的say_hello和数字8001关联起来了。

回到readPermissions,readPermissions()完成后会调用scanDirLI扫描系统中安装的apk,它调用scanPackageLI建立每个apk的配置结构PackageSetting(继承于上面提到的PackageSettingBase),并把mSettings.mPermissions中保存的权限与之相关联。然后调用updatePermissionsLPw更新mSettings.mPermissions列表。

frameworks/base/services/java/com/android/server/pm/PackageManagerService.java

可以看到如果权限的packageSetting为空,则将被从列表中删除。所以,只在platform.xml中定义了权限是不够的。必须有包声明这个权限,从而使bp.packageSetting不为空(前面说过,scanPackageLI会将权限和包配置关联起来)。像INTERNET这样的系统权限是在framework-res.apk(包名是android)中声明的:

frameworks/base/core/res/AndroidManifest.xml

所以我们也在frameworks/base/core/res/AndroidManifest.xml中添加如下内容:

至此,我们就完成了say_hello权限的定义。

实现过程总结:

1、在platform.xml中添加

2、在android_filesystem_config.h中添加

在android_ids数组中添加

3、在frameworks/base/core/res/AndroidManifest.xml中添加

4、将frameworks/base/data/etc/platform.xml push到/etc/permissions/下
5、执行mmm bionic/libc/ 编译出libc.so,并将其push到/system/lib下
6、执行mmm frameworks/base/core/res/编译出framework-res.apk,并将其push到/system/framework下
完成,可以在android应用中验证成果了!

 

另一个问题,我们的应用场景是在C语言中管理权限,那么如何在C语言中获取各应用的权限呢?
其实,在PackageManagerService初始化所有包信息之后就会调用mSettings.writeLPr()(只要系统中包的信息有改变,比如安装应用,都会调用这个函数)。

frameworks/base/services/java/com/android/server/pm/Settings.java

mPackageListFilename.getAbsolutePath()的结果是/data/system/packages.list,这段代码的任务就是将mPackages中保存的所有包的信息保存到/data/system/packages.list.tmp,保存的内容和格式见注释。如果这个过程没有出错,最后调用journal.commit()将/data/system/packages.list.tmp重命名为/data/system/packages.list覆盖原来的文件。
所以,/data/system/packages.list中保存了所有应用申请的权限,C代码只要读这个文件就能判断某个应用是否申请了我们要求的权限。
通常情况下,在接收到应用的请求时,我们不愿意每次都读取这个文件然后解析、判断这个应用的gids中是否有我们定义的id,更好的做法是将所有申请了权限的包缓存起来,这样就不必每次都读文件。而且,writeLPr更新这个文件的方法是直接用新文件覆盖旧文件,所以我们只需要监听这个文件的删除事件,在事件发生时,更新缓存。下面的代码片段是一个使用这种方法的例子。