android sdcard 权限管理策略研究

自从android4.4 以来，第三方应用程序是不能再随便的访问sdcard了，从开发者的角度而言，研究一下android系统到底是怎么样来实现这样的控制还是比较有价值的。

首先分析下现状，现在已知，对于内部存储系统android的控制策略还是没有多大改变的，内部sdcard还是可以在申请了android.permission.WRITE_EXTERNAL_STORAGE

这个权限后随便访问的，而对于外置sdcard就没那么方便。网络上一般的说法是只有内置app才可以访问，其他的app就只能限定/data/data/Package_name/ 的目录下。

那具体这个差别是怎么实现的呢？

首先sdcard的权限管理是fuse 即用户空间文件系统（Filesystem in Userspace）来实现的，一旦使用了fuse，文件的访问权限就不在是单纯的Linux的ACL机制，不能光凭借文件的umask来判断谁具有读写权限了。以5.0为例：

drwxrwx--- root sdcard_r 2014-01-01 07:47 Alarms

drwxrwx--x root sdcard_r 2014-01-01 07:47 Android

drwxrwx--- root sdcard_r 2014-01-02 06:35 DCIM

drwxrwx--- root sdcard_r 2014-01-01 07:47 Download

即使app的gid加入了sdcard_r甚至sdcard_rw也是不能访问这些目录了。原因就是这个fuse的机制。本质上android的fuse并不是正统的fuse，而是fuse代码的重写，以sdcard的deamo的形式存在在android系统中，这个是google说的。

那么找到sdcard的deamo的实现就可以找到线索了。在android源码system/core/sdcard中可以找sdcard.c这么个文件。它最终被编译成为sdcard可执行程序，这就是所谓的sdcard的守护进程。查看它的代码可以发现它在初始化以后就跑了一个for (;;)的循环，一直从/dev/fuse这个设备中读取请求，然后交给handle_fuse_request去处理。从Android的整体设计原则来猜想，这又是一个CS的典型结构，即只有这个进程可以进行真正意义上的读写操作，上层的对于sdcard的io操作，实际上是通过/dev/fuse交给这个守护进程来处理的。

事实上是这样吗。来看下sdcard是谁启动的：

---

service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated

class late_start

service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1

class late_start

disabled

---

这个是init.rc中的片段，/system/bin/sdcard 启动时候加了很多参数

-u 1023 应该是uid

-g 1023 应该是gid

-l /data/media /mnt/shell/emulated 这个表示的什么要看代码实现了，代码里前一个是source_path 后一个dest_path, dest_path挂载了/dev/fuse。

根据经验来猜测，上层针对 /mnt/shell/emulated的操作本质上是对/data/media 的操作，但是中间夹杂着fuse的处理，必须由sdcard这个程序来决定真正的操作。

drwxrwx--- media_rw media_rw 2014-01-01 07:47 media

可以发现这个目录的uid和gid都是media_rw, 而 # ps -c sdcard

USER PID PPID VSIZE RSS CPU WCHAN PC NAME

media_rw 2098 1 16232 1120 4 ffffffff 9b64f1d4 S /system/bin/sdcard

发现这个进程的user正式media_rw,这样就和之前的猜测不谋而合了。即，只有/system/bin/sdcard 能够真正的操作/data/media ，而/data/media 真是虚拟的sdcard的本尊！

所有对与虚拟sdcard的操作都通过fuse的设计，经kernel从/dev/fuse又给/system/bin/sdcard 这个进程，由它来正真的handle请求。 Ok，大概的逻辑就是这样了，详细的实现还是要从代码中去学习。

问题回到原来的，为什么内置sdcard可以随便访问，而外置不行呢。答案还在代码中，查看sdcard.c中对于创建文件的处理，

static int handle_mknod(struct fuse* fuse, struct fuse_handler* handler,

const struct fuse_in_header* hdr, const struct fuse_mknod_in* req, const char* name)

{

bool has_rw;

struct node* parent_node;

char parent_path[PATH_MAX];

char child_path[PATH_MAX];

const char* actual_name;

pthread_mutex_lock(&fuse->lock);
has_rw = get_caller_has_rw_locked(fuse, hdr);
parent_node = lookup_node_and_path_by_id_locked(fuse, hdr->nodeid,
        parent_path, sizeof(parent_path));
TRACE("[%d] MKNOD %s 0%o @ %"PRIx64" (%s)\n", handler->token,
        name, req->mode, hdr->nodeid, parent_node ? parent_node->name : "?");
pthread_mutex_unlock(&fuse->lock);

if (!parent_node || !(actual_name = find_file_within(parent_path, name,
        child_path, sizeof(child_path), 1))) {
    return -ENOENT;
}
if (!check_caller_access_to_name(fuse, hdr, parent_node, name, W_OK, has_rw)) {
    return -EACCES;
}
__u32 mode = (req->mode & (~0777)) | 0664;
if (mknod(child_path, mode, req->rdev) < 0) {
    return -errno;
}
return fuse_reply_entry(fuse, hdr->unique, parent_node, name, actual_name, child_path);

}

其中check_caller_access_to_name 是关键，因为他会返回EACCES！

static bool check_caller_access_to_name(struct fuse* fuse,

const struct fuse_in_header hdr, const struct node parent_node,

const char* name, int mode, bool has_rw) {

/* Always block security-sensitive files at root */

if (parent_node && parent_node->perm == PERM_ROOT) {

if (!strcasecmp(name, "autorun.inf")

|| !strcasecmp(name, ".android_secure")

|| !strcasecmp(name, "android_secure")) {

return false;

}

}

/* No additional permissions enforcement */
if (fuse->derive == DERIVE_NONE) {
    return true;
}

/* Root always has access; access for any other UIDs should always
 * be controlled through packages.list. */
if (hdr->uid == 0) {
    return true;
}

/* If asking to write, verify that caller either owns the
 * parent or holds sdcard_rw. */
if (mode & W_OK) {
    if (parent_node && hdr->uid == parent_node->uid) {
        return true;
    }

    return has_rw;
}

/* No extra permissions to enforce */
return true;

}

注释写的比较清楚就不多分析了，重点是has_rw ，这个谁决定

has_rw = get_caller_has_rw_locked(fuse, hdr);

get_caller_has_rw_locked的实现

/* Return if the calling UID holds sdcard_rw. /

static bool get_caller_has_rw_locked(struct fuse fuse, const struct fuse_in_header hdr) {

/ No additional permissions enforcement */

if (fuse->derive == DERIVE_NONE) {

return true;

}

  appid_t appid = multiuser_get_app_id(hdr->uid);
  return hashmapContainsKey(fuse->appid_with_rw, (void*) (uintptr_t) appid);

}

hashmapContainsKey这个方法，看appid是不是在appid_with_rw 这个map中，那这个map是哪里来的呢？通过追踪可以发现时通过/data/system/packages.list这个文件解析得出的。

 if (strtoul(token, NULL, 10) == fuse->write_gid) {
	  hashmapPut(fuse->appid_with_rw, (void*) (uintptr_t) appid, (void*) (uintptr_t) 1);
	  break;
}

这段代码在解析packages.list中的每一行，如果有gid = fuse->write_gid的那就会被加到这个Hashmap中了。

com.android.providers.downloads.ui 10005 0 /data/data/com.android.providers.downloads.ui default 1028,1015,1023,1024,2001,3003,3007

com.android.pacprocessor 10040 0 /data/data/com.android.pacprocessor platform 3003

com.android.certinstaller 10024 0 /data/data/com.android.certinstaller platform none

com.android.speechrecorder 10050 0 /data/data/com.android.speechrecorder default none

android 1000 0 /data/system platform 1028,1015,3002,3001,3003

那fuse->write_gid 是什么呢？

gid_t write_gid = AID_SDCARD_RW; 这是初始化时候的值，AID_SDCARD_RW 在system/core/include/private/android_filesystem_config.h中有定义， 1015正是sdcard_rw的group id。

但是，但是，还记得init.rc里面的 -w吗？

service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1

这个-w的值就覆盖了write_gid ， 1023是什么gid？

define AID_MEDIA_RW 1023

ok，正是media_rw的group id。

AID_SDCARD_RW 和 AID_MEDIA_RW 有什么差别，怎么才能加入这个对应group呢？

android权限管理机制，加permission呗。那来看看对应的permission是怎么声明的。

<permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
    android:permissionGroup="android.permission-group.STORAGE"
    android:label="@string/permlab_sdcardWrite"
    android:description="@string/permdesc_sdcardWrite"
    android:protectionLevel="dangerous" />

<!-- @SystemApi Allows an application to write to internal media storage
     @hide  -->
<permission android:name="android.permission.WRITE_MEDIA_STORAGE"
    android:permissionGroup="android.permission-group.STORAGE"
    android:label="@string/permlab_mediaStorageWrite"
    android:description="@string/permdesc_mediaStorageWrite"
    android:protectionLevel="signature|system" />

要加入sdcard_rw组需要加android.permission.WRITE_EXTERNAL_STORAGE，

要加入media_rw组需要加android.permission.WRITE_MEDIA_STORAGE。

Ok，真相大白了！ WRITE_EXTERNAL_STORAGE的protectionLevel 仅仅是dangerous， 而WRITE_MEDIA_STORAGE的protectionLevel 是signature|system， 这就是为什么第三方应用程序不能随便访问sdcard的原因！

转载自：https://blog.csdn.net/louyong0571/article/details/45046163