android sdcard 权限管理策略研究

最新推荐文章于 2021-05-29 16:30:50 发布

louyong0571

最新推荐文章于 2021-05-29 16:30:50 发布

阅读量3.3k

点赞数 1

分类专栏： android

本文链接：https://blog.csdn.net/louyong0571/article/details/45046163

版权

android 专栏收录该内容

28 篇文章 1 订阅

订阅专栏

自从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的原因！