在 Android 2.x 时代，由于成本和技术限制，Android 手机往往需要插入一张外置 sd 卡作为 “媒体区”（/sdcard） (1)。由于这张 sd 卡常常需要在手机插入电脑时重新挂载到 windows 上以方便数据拷贝，因此它多采用 FAT32 格式。这种格式与手机内置存储的格式是不同的(2) ：它对大小写不敏感，也不支持 Unix 文件权限。

(1) 那时没插 sd 卡手机也能正常运行，只是没法保存图片之类的，微信里看照片都是黑框框。
(2) 旧时代的内置存储往往采用 ext4 格式，近些年来被 f2fs 逐步取代。这里的内置存储是指 /data 区。

随着技术的进步和对性能需求的提升，手机开始有了足够的容量将这张外置 sd 卡整合进内置存储。那么问题来了，我该如何分配手机的空间？还是像原来那样独立的分一个分区给 sd 卡吗？那要分多大？这样空间利用率岂不是贼差？很显然，独立的分一个分区出来是不实用的。Android 采用的方案是将原本的外置 sd 卡整体塞进 /data 里，放在 /data/media，再经过一些处理将其映射到原来的 /sdcard。之所以要经过处理，是因为 /data/media 目录是受 Unix 文件权限保护的，直接映射（比如 bind mount ）轻则 Permission denied ，重则应用利用自己的 uid、gid 在里面瓜分领地，互设屏障。这和原来共享的外置 sd 卡就完全不同了。除此之外，内置存储是文件系统往往是区分大小写的，这也和原来的外置 sd 卡不同。为了兼容性，我们必须对这个映射过程进行处理，使它表现的就和原来的 FAT32 一样。这便是 "Emulated"。

随着 Android 版本的迭代，"Emulated" 的实现方式也发生着变化。在较早的 Android 版本上其采用 FUSE 实现，在 Android O 上谷歌采用性能更好的 SDCardFS 取代了 FUSE ，而在 Android 11 上他又改了回去，SDCardFS 惨遭弃用。在这篇文章中我不打算考古，故不会去研究上古时期是如何使用 FUSE 的。我们会从 SDCardFS 开始来看看它的工作机制，再看看能不能为谷歌在 Android 11 切回 FUSE 找到一些正当理由。

SDCardFS

简介

SDCardFS 是一个纯内核侧的驱动，它的大多数配置只能在 mount 时设置好，不能动态调整。正因如此，它与用户空间的交互更少，具有更好的性能(1)。

(1) 相对于 FUSE 而言，FUSE 将在后面再介绍。

SDCardFS 所做的工作，概括一下就是“处理”和“转发”，又或者说就是上面的“模拟”。
“处理”是按上面所说，尽可能让它看起来像一个 FAT32 文件系统。
“转发”便是将用户（“上层”）在其上的操作转交给“下层文件系统”，在 “模拟存储” 中也就是转交给 /data/media 。下面的内容主要关注“处理”，“转发”实在是有点乏味。

SDCardFS 的挂载由 vold 发起，vold 会 fork() 出一个子进程来运行一个名为 sdcard 的可执行文件，而它所做的事情便是调用 mount wrapper ，按照预定义的挂载点位置挂载 SDCardFS ，并传入对应的挂载参数。

接下来，我将介绍几个重要的挂载参数并看看它们的功能，然后再看看它们是如何与 Android 系统相配合使用的。

挂载参数

这里只挑几个我认为重要且与系统配合密切的参数进行介绍，剩下的请自行 READ THE FUCKING SOURCE CODE 。
重要的挂载参数包括：fsuid=<>、fsgid=<>、gid=<>、mask=<> (1) 等。

(1) <> 代表填入配置内容，比如 gid=9997 。

gid

这个参数代表了从 “上层”(1) 视角看到和被验证的，文件或文件夹的组号。

SDCardFS 可以覆盖 “下层”(2) 文件系统的文件所有者信息(3)，向“上层”汇报并使用特定的文件所有者信息。
这就解决了上面提及的 Unix 文件权限问题中的所有者问题，应用不再能够利用文件所有者信息来互设访问门槛，因为这些所有者信息最终会被 SDCardFS 覆写。

(1) “上层” 指通过 SDCardFS 挂载点访问的进程。比如应用访问 emulated storage 时，应用就是这里的“上层”。
(2) “下层” 指真正存储数据的地方，也就是上面所说的“转发”的目的地。
(3) 这里的“所有者”包含 owner + group 。

从代码角度看看：

kernel/fs/sdcardfs/inode.c

static int sdcardfs_permission(struct vfsmount *mnt, struct inode *inode, int mask)
{
    ......
    copy_attrs(&tmp, inode);
    tmp.i_uid = make_kuid(&init_user_ns, top->d_uid);
    tmp.i_gid = make_kgid(&init_user_ns, get_gid(mnt, inode->i_sb, top));
    ......
}

kernel/fs/sdcardfs/sdcardfs.h

static inline int get_gid(struct vfsmount *mnt,
        struct super_block *sb,
        struct sdcardfs_inode_data *data)
{
    struct sdcardfs_vfsmount_options *vfsopts = mnt->data;
    ......
        return multiuser_get_uid(data->userid, vfsopts->gid);
}

这里只列出权限检查中的一处示意一下，还有汇报权限之类的这里就不举例了。
从上方代码中可以看到，对上层只有 gid 是可自行配置的，其存储在 sdcardfs_vfsmount_options 结构体的 gid 中。

fsuid、fsgid

这俩代表了非特殊文件 / 文件夹要以何种所有者和组身份在“下层”文件系统上存储。
至于为什么要以特定身份存储，我想首先是为了整齐，然后也为系统中的部分服务保留了访问的权限吧。

从代码角度看看：

kernel/fs/sdcardfs/inode.c

const struct cred *override_fsids(struct sdcardfs_sb_info *sbi,
        struct sdcardfs_inode_data *data)
{
    struct cred *cred;
    const struct cred *old_cred;
    uid_t uid;

    cred = prepare_creds();
    if (!cred)
        return NULL;

    if (sbi->options.gid_derivation) {
        if (data->under_obb)
            uid = AID_MEDIA_OBB;
        else
            uid = multiuser_get_uid(data->userid, sbi->options.fs_low_uid);
    } else {
        uid = sbi->options.fs_low_uid;
    }
    cred->fsuid = make_kuid(&init_user_ns, uid);
    cred->fsgid = make_kgid(&init_user_ns, sbi->options.fs_low_gid);

    old_cred = override_creds(cred);

    return old_cred;
}

可以看到，对下层使用的 uid 和 gid 分别存储在 sdcardfs_mount_options 结构体的 fs_low_uid 与 fs_low_gid 中。

上面的方法进行的是对调用者进程 credential 的修改。这种修改有点 Binder.clearCallingIdentity() 内味儿，只不过它所给以的身份是预定义的。于是内核态的进程就继续拿着预定义的身份向下访问“下层”文件系统，顺理成章的，“下层”文件系统中留下的 uid 和 gid 也就是预定义的了。和 Binder 类似，SDCardFS 在完成这一操作后也会通过 revert_fsids(saved_cred); 来还原进程本身具有的 uid 和 gid ，从而避免被提权。

SDCardFS 在一批 inode_operations （如 mkdir、create、setattr）中进行了上述替换 + 下层访问 + 还原的操作，从而实现了以特定所有者和组身份在“下层”文件系统上存储文件。

mask

这个玩意儿，主要起到的是对“上层”覆盖权限的作用，即使得从“上层”视角看到和被验证的是经过处理的权限。上面 gid 的作用方向也是“上层”，但是它的作用对象是单纯的组号，而 mask 的作用对象便是“权限”本身。

康康代码：

kernel/fs/sdcardfs/sdcardfs.h

static inline int get_mode(struct vfsmount *mnt,
        struct sdcardfs_inode_info *info,
        struct sdcardfs_inode_data *data)
{
    int owner_mode;
    int filtered_mode;
    struct sdcardfs_vfsmount_options *opts = mnt->data;
    int visible_mode = 0775 & ~opts->mask;


    if (data->perm == PERM_PRE_ROOT) {
        /* Top of multi-user view should always be visible to ensure
        * secondary users can traverse inside.
        */
        visible_mode = 0711;
    } else if (data->under_android) {
        /* Block "other" access to Android directories, since only apps
        * belonging to a specific user should be in there; we still
        * leave +x open for the default view.
        */
        if (opts->gid == AID_SDCARD_RW)
            visible_mode = visible_mode & ~0006;
        else
            visible_mode = visible_mode & ~0007;
    }
    owner_mode = info->lower_inode->i_mode & 0700;
    filtered_mode = visible_mode & (owner_mode | (owner_mode >> 3) | (owner_mode >> 6));
    return filtered_mode;
}

mask 存储在 sdcardfs_vfsmount_options 结构体的 mask 成员变量中。
可以看到，它是作为掩码存在，掩去对应的权限位从而使“上层”进程失去对应的访问权限。

一般的权限处理过程是这样的：预设一个最高权限，这里是 775 ，然后应用 mask 掩去对应的权限，比如 mask 为 007 时，得到的“可见权限”就是 750 。然后“可见权限”会和“下层”文件系统上的 owner 权限取与（说白了就是哪个权限最低取哪个），得到最终要展示给“上层”的权限。比如文件在“下层”文件系统上的权限是 600 ，因为它是和 owner 权限取与，所以相当于要计算 750 & 666 ，得到的自然是 640 ，而这也是最终展示给“上层”的权限。

需要注意的是，上面的权限数字都是八进制的形式。在 C 语言中，0 开头表示的数字都是八进制，这就是为什么上面的代码中的权限均是 0 开头的。但是，采用 mask=<> 挂载参数传入的权限是十进制的形式，因此还要进行一个换算。

可能有点复杂，但，不管咋样，mask 就是用来给权限“降级”的，从而施加更加严格的访问控制。

忽略大小写

嗯，这不是什么复杂的东西，SDCardFS 中有几个内联函数专门负责这项功能：

kernel/fs/sdcardfs/sdcardfs.h

static inline bool str_case_eq(const char *s1, const char *s2)
{
    return !strcasecmp(s1, s2);
}

static inline bool str_n_case_eq(const char *s1, const char *s2, size_t len)
{
    return !strncasecmp(s1, s2, len);
}

static inline bool qstr_case_eq(const struct qstr *q1, const struct qstr *q2)
{
    return q1->len == q2->len && str_n_case_eq(q1->name, q2->name, q2->len);
}

凡是遇到比较 dentry->d_name（文件/目录名）的，都进来用这个判断就好啦。

与系统相配合

这一块内容，主要讲述 SDCardFS 是如何与系统相配合从而实现权限控制的。
由于 SDCardFS 已经 legacy 再加上我懒得去研究历史，因此下面的内容存在一定的瞎猜成分。

铺垫：应用所在组

从上面可以看到，我们可以在挂载 SDCardFS 时通过传入参数 gid=<> 来为“上层”使用特定的组号。但是，这有什么用吗？“上层”得首先具有这个 gid 才能拥有操作的权限诶。但是应用的 gid 不是由系统分配的吗，不同应用甚至会被分到不同的 gid，那该如何统一的管理权限呢？

于是 Android 复用了 Linux 内核的 groups （supplementary groups）机制(1) ，属于同一用户(2) 的应用进程会被加入到对应用户的 EVERYBODY 组中：

services/core/java/com/android/server/am/ProcessList.java

private int[] computeGidsForProcess(int mountExternal, int uid, int[] permGids,
        boolean externalStorageAccess) {
    ArrayList<Integer> gidList = new ArrayList<>(permGids.length + 5);

    ......
    final int userGid = UserHandle.getUserGid(UserHandle.getUserId(uid));

    ......
    if (userGid != UserHandle.ERR_GID) {
        gidList.add(userGid);
    }
    ......
}

上面的 UserHandle.getUserGid() 会返回对应用户的 EVERYBODY 组号。

既然一个用户下的所有进程都具有一个相同的 group ，那么，我们只要传入 gid=<这个组号> 就可以授予一批应用访问权限了。

至于这个机制的应用，会在下一小节内容中提及。

(1) 详见上面的铺垫文章，里面有对其应用的更多举例。
(2) 这里的“用户”是指 Android 的多用户机制，而非上面的 uid 。

权限与多视图

自从 Android 6.0 以来，Android 开始引入了动态权限系统（运行时权限）：用户可以在应用运行时，通过授权弹窗，动态的授予应用对外部存储的访问权限。
这也就意味着，不同的应用需要具有不同的外部存储视图：对于没有权限的应用，/sdcard/Android 下的应用包名文件夹应该是随时可以读写的；对于有读权限的应用，在上一条的基础上加上对其它文件的读取权限；对于有写权限的应用，在上一条的基础上再加上写权限。

但是，SDCardFS 作为纯内核侧的驱动，并不能实时与系统服务通信去了解应用的授权状态。因此，Android 采用了将 SDCardFS 挂载多次的方式来提供不同的视图：

system/core/sdcard/sdcard.cpp

static void run_sdcardfs(const std::string& source_path, const std::string& label, uid_t uid,
                         gid_t gid, userid_t userid, bool multi_user, bool full_write,
                         bool derive_gid, bool default_normal, bool unshared_obb, bool use_esdfs) {
    std::string dest_path_default = "/mnt/runtime/default/" + label;
    std::string dest_path_read = "/mnt/runtime/read/" + label;
    std::string dest_path_write = "/mnt/runtime/write/" + label;
    std::string dest_path_full = "/mnt/runtime/full/" + label;

    ......
    if (multi_user) {
        // Multi-user storage is fully isolated per user, so "other"
        // permissions are completely masked off.
        if (!sdcardfs_setup(source_path, dest_path_default, uid, gid, multi_user, userid,
                            AID_SDCARD_RW, 0006, derive_gid, default_normal, unshared_obb,
                            use_esdfs) ||
            !sdcardfs_setup_secondary(dest_path_default, source_path, dest_path_read, uid, gid,
                                      multi_user, userid, AID_EVERYBODY, 0027, derive_gid,
                                      default_normal, unshared_obb, use_esdfs) ||
            !sdcardfs_setup_secondary(dest_path_default, source_path, dest_path_write, uid, gid,
                                      multi_user, userid, AID_EVERYBODY, full_write ? 0007 : 0027,
                                      derive_gid, default_normal, unshared_obb, use_esdfs) ||
            !sdcardfs_setup_secondary(dest_path_default, source_path, dest_path_full, uid, gid,
                                      multi_user, userid, AID_EVERYBODY, 0007, derive_gid,
                                      default_normal, unshared_obb, use_esdfs)) {
            LOG(FATAL) << "failed to sdcardfs_setup";
        }
    } ......
}

几个挂载点按照以下策略进行挂载(1)：

/mnt/runtime/default/emulated 采用 gid=<AID_SDCARD_RW>,mask=<0006> 挂载。
/mnt/runtime/read/emulated 采用 gid=<AID_EVERYBODY>,mask=<0027> 挂载。
/mnt/runtime/write/emulated 采用 gid=<AID_EVERYBODY>,mask=<0007> 挂载。
还有个 full，挂载策略和 write 相同，此处不再介绍。

每个应用都运行在自己的“挂载命名空间”中，Android 会根据“动态权限”的授权状况，在对应的“挂载命名空间”中 bind mount 上述挂载点：

没有权限： /mnt/runtime/default/emulated -> /storage/emulated。
有读权限（READ_EXTERNAL_STORAGE）： /mnt/runtime/read/emulated -> /storage/emulated。
有写权限（WRITE_EXTERNAL_STORAGE）： /mnt/runtime/write/emulated -> /storage/emulated。

/storage/emulated/<用户号>(2) 会被 symlink 到 /storage/self/primary，然后再被 symlink 到 /sdcard ，从而成为我们熟悉的外置存储(3)。

(1) 这里面的 <xxx> 不代表实际传入挂载参数的值。gid 传入的是组号，上面以组名示意。mask 传入的是十进制形式，上面的是八进制，还需要进行一次转换。
(2) 关于这个<用户号>，会在后面介绍多用户机制的时候再提及。
(3) 没有具体考证在旧版 Android 系统上这条 symlink 路径是否仍然成立，仅供参考。

接下来看看上面的挂载参数是如何配合到权限控制的：

首先，对于具有读权限的应用，挂载参数中的 gid 为 EVERYBODY。经过上面的铺垫我们知道所有应用都属于对应的 EVERYBODY 组，因此所有应用都具有“组权限”。然后呢，根据 mask 我们可以看到，组的对应位是 2 ，也就是说写权限被掩去了，应用只具有读权限，这便与 Android 动态权限系统所给以的权限相吻合。

其次，对于具有写权限的应用，挂载参数中 gid 与上面的读权限是相同的，但是 mask 中组的对应位为 0 ，不再掩去任何东西。按照上面描述的权限计算方法可以得出此时应用是具有写入权限的，与系统的动态权限系统相吻合。

接下来是神奇的针对没有权限应用的 default ，其挂载参数中的 gid 是 SDCARD_RW ，一般的应用程序可不在这个组里面(1)，自然也就拿不到组权限。那么问题来了，没有权限时应用被允许干啥？还记得上面的需求吗？即使没有请求存储权限，应用也是可以访问它们在 Android 目录下的包名文件夹的，那这是怎么做到的呢？

请看下一小节的内容 :)

另外，mask 中“其它”的对应位是 7 (2)，也就是掩去了所有权限，也就是说不属于该用户的应用无权对该用户的文件进行访问（指 Android 多用户机制，这里只作提及，下面再介绍）。

(1) 这个组里的东西往往是特权系统服务，比如 MTP 。
(2) 虽然 default 的是 6 ，但是好像并没有卵用，按照我们上面的分析，执行权限要生效则下层源文件的所有者必须具有执行权限，但是创建的新文件默认并没有执行权限，而 SDCardFS 设置了 Inode Attributes 使得用户无法修改权限，我们压根就无法通过常规操作使一个文件具有执行权限。因此这个执行位是留给谁用的我暂且还蒙在鼓里。是给 Android 目录用的，至于有什么用，仍然蒙在鼓里...

针对 Android 目录的特殊处理

从上面的内容中可以知道，SDCardFS 还需要处理一个特别棘手的需求，那就是应用在没有存储权限时也需要能够访问自己在 Android 目录下对应的“包名目录”，那么，它是如何做到的呢？

概括一下，还是利用上面基于 uid、gid、groups 的文件系统访问控制。

SDCardFS 在执行 lookup() 建立 dentry 时，会调用 get_derived_permission_new() ，根据父目录的类型和子目录的名称，确定子目录的类型，并将其装进 sdcardfs inode 中：

kernel/fs/sdcardfs/derived_perm.c

void get_derived_permission_new(struct dentry *parent, struct dentry *dentry,
                const struct qstr *name)
{
    struct sdcardfs_inode_info *info = SDCARDFS_I(d_inode(dentry));
    struct sdcardfs_inode_info *parent_info = SDCARDFS_I(d_inode(parent));
    struct sdcardfs_inode_data *parent_data = parent_info->data;
    appid_t appid;
    unsigned long user_num;
    int err;
    struct qstr q_Android = QSTR_LITERAL("Android");
    struct qstr q_data = QSTR_LITERAL("data");
    struct qstr q_sandbox = QSTR_LITERAL("sandbox");
    struct qstr q_obb = QSTR_LITERAL("obb");
    struct qstr q_media = QSTR_LITERAL("media");
    struct qstr q_cache = QSTR_LITERAL("cache");

    /* By default, each inode inherits from its parent.
     * the properties are maintained on its private fields
     * because the inode attributes will be modified with that of
     * its lower inode.
     * These values are used by our custom permission call instead
     * of using the inode permissions.
     */

    inherit_derived_state(d_inode(parent), d_inode(dentry));

    /* Files don't get special labels */
    if (!S_ISDIR(d_inode(dentry)->i_mode)) {
        set_top(info, parent_info);
        return;
    }
    /* Derive custom permissions based on parent and current node */
    switch (parent_data->perm) {
    case PERM_INHERIT:
    case PERM_ANDROID_PACKAGE_CACHE:
        set_top(info, parent_info);
        break;
    case PERM_PRE_ROOT:
        /* Legacy internal layout places users at top level */
        info->data->perm = PERM_ROOT;
        err = kstrtoul(name->name, 10, &user_num);
        if (err)
            info->data->userid = 0;
        else
            info->data->userid = user_num;
        break;
    case PERM_ROOT:
        /* Assume masked off by default. */
        if (qstr_case_eq(name, &q_Android)) {
            /* App-specific directories inside; let anyone traverse */
            info->data->perm = PERM_ANDROID;
            info->data->under_android = true;
        } else {
            set_top(info, parent_info);
        }
        break;
    case PERM_ANDROID:
        if (qstr_case_eq(name, &q_data)) {
            /* App-specific directories inside; let anyone traverse */
            info->data->perm = PERM_ANDROID_DATA;
        } else if (qstr_case_eq(name, &q_sandbox)) {
            /* App-specific directories inside; let anyone traverse */
            info->data->perm = PERM_ANDROID_DATA;
        } else if (qstr_case_eq(name, &q_obb)) {
            /* App-specific directories inside; let anyone traverse */
            info->data->perm = PERM_ANDROID_OBB;
            info->data->under_obb = true;
            /* Single OBB directory is always shared */
        } else if (qstr_case_eq(name, &q_media)) {
            /* App-specific directories inside; let anyone traverse */
            info->data->perm = PERM_ANDROID_MEDIA;
        } else {
            set_top(info, parent_info);
        }
        break;
    case PERM_ANDROID_OBB:
    case PERM_ANDROID_DATA:
    case PERM_ANDROID_MEDIA:
        info->data->perm = PERM_ANDROID_PACKAGE;
        appid = get_appid(name->name);
        if (appid != 0 && !is_excluded(name->name, parent_data->userid))
            info->data->d_uid =
                multiuser_get_uid(parent_data->userid, appid);
        break;
    case PERM_ANDROID_PACKAGE:
        if (qstr_case_eq(name, &q_cache)) {
            info->data->perm = PERM_ANDROID_PACKAGE_CACHE;
            info->data->under_cache = true;
        }
        set_top(info, parent_info);
        break;
    }
}

截取关键部分：

case PERM_ANDROID_OBB:
case PERM_ANDROID_DATA:
case PERM_ANDROID_MEDIA:
    info->data->perm = PERM_ANDROID_PACKAGE;
    appid = get_appid(name->name);
    if (appid != 0 && !is_excluded(name->name, parent_data->userid))
        info->data->d_uid =
            multiuser_get_uid(parent_data->userid, appid);
    break;

当父目录是 Android/data、Android/obb 或 Android/media 时，也就是说，子目录是“包名目录”，此时子目录的名称（包名）会被塞给 get_appid() 转换为该应用的 uid ，然后被塞进 sdcardfs inode 中。于是，“包名目录”的 owner 就变成了该包名对应的应用的 uid ，那么这个应用就顺理成章的拥有了对自己“包名目录”的访问权限。

这个过程不能说非常 hacky ，只能说非常有针对性。。。

那么问题来了，SDCardFS 是一个纯内核侧的东西，它是怎么知道哪个包名对应的 uid 是多少的？我们在挂载的时候也没告诉它啊！

诶，那开个洞特地告诉它一下不就行了么？

kernel/fs/sdcardfs/Kconfig

config SDCARD_FS
    tristate "sdcard file system"
    depends on CONFIGFS_FS
    default n
    help
      Sdcardfs is based on Wrapfs file system.

毕竟，人家可是 depends on CONFIGFS_FS 的，随时已经准备好开洞了。

OnePlus8T:/ # ls /config/sdcardfs/
android                                                        com.android.providers.downloads
android.auto_generated_rro_vendor__                            com.android.providers.downloads.ui
......

OnePlus8T:/ # ls /config/sdcardfs/com.android.launcher3
appid  clear_userid  excluded_userids
OnePlus8T:/ # cat /config/sdcardfs/com.android.launcher3/appid
10100

我们可以在 configfs 的挂载点 /config 下找到 SDCardFS 开的洞：/config/sdcardfs/ 下有一大堆以应用包名命名的目录，而每一个目录中又有名为 appid 的文件，应用的 uid(1) 就被这么硬生生的写了进去。。。

(1) 其实这里写进去的东西叫做 appId ，但是对于用户 0 ，它与 uid 是基本等同的，参见“针对多用户的特殊处理”。

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

void writeKernelMappingLPr(String name, int appId, int[] excludedUserIds) {
    KernelPackageState cur = mKernelMapping.get(name);
    final boolean firstTime = cur == null;
    final boolean userIdsChanged = firstTime
            || !Arrays.equals(excludedUserIds, cur.excludedUserIds);

    // Package directory
    final File dir = new File(mKernelMappingFilename, name);

    if (firstTime) {
        dir.mkdir();
        // Create a new mapping state
        cur = new KernelPackageState();
        mKernelMapping.put(name, cur);
    }

    // If mapping is incorrect or non-existent, write the appid file
    if (cur.appId != appId) {
        final File appIdFile = new File(dir, "appid");
        writeIntToFile(appIdFile, appId);
        if (DEBUG_KERNEL) Slog.d(TAG, "Mapping " + name + " to " + appId);
    }

    ......
}

这一切，是由 PackageManagerService 直接负责的。

针对多用户的特殊处理

Android 本身自带了一个多用户机制。不同用户具有相互隔离的应用数据和“模拟存储”。很显然，SDCardFS 需要对此进行支持。
这里的“用户”并不是指上面的 uid ，而是一个真正的 Android 用户。不同用户可以安装不同的应用，而这些应用又具有对应的 uid 。

不同用户的“模拟存储”数据在“下层”文件系统上是以文件夹的方式分隔存储的，比如“主用户”（用户号为 0 ）的数据存储在 /data/media/0 ，副用户（比如用户号为 10 ）的数据存储在 /data/media/10 。

SDCardFS 并不会为多个用户进行多次挂载，它在被挂载时传入的是整个 /data/media 而非特定的用户目录。这意味着，SDCardFS 的“根目录”是一个有着一堆用户文件夹的“多用户视图”。

于是，在执行 lookup() 创建 dentry 时，SDCardFS 会调用 get_derived_permission_new() 根据其“根目录”的文件夹名，将用户号记录下来，并让它的子目录也继承这些数据。这便是它得知目前的操作对象位于哪个用户的方式。

kernel/fs/sdcardfs/derived_perm.c

void get_derived_permission_new(struct dentry *parent, struct dentry *dentry,
                const struct qstr *name)
{
    ....
    case PERM_PRE_ROOT:
        /* Legacy internal layout places users at top level */
        info->data->perm = PERM_ROOT;
        err = kstrtoul(name->name, 10, &user_num);
        if (err)
            info->data->userid = 0;
        else
            info->data->userid = user_num;
        break;
    ......
}

那么，面对多用户，它需要做些什么呢？

不妨先看看 Android 本身需要些什么。
不同的应用一般具有不同的 uid ，这是众所周知的。那么，不同用户下的相同应用，它们的 uid 是相同的还是不同的呢？答案是不同，但是却有规律：

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

/**
 * @hide Range of uids allocated for a user.
 */
@UnsupportedAppUsage
public static final int PER_USER_RANGE = 100000;
......
/**
 * Returns the uid that is composed from the userId and the appId.
 * @hide
 */
@UnsupportedAppUsage
@TestApi
public static int getUid(@UserIdInt int userId, @AppIdInt int appId) {
    if (MU_ENABLED) {
        return userId * PER_USER_RANGE + (appId % PER_USER_RANGE);
    } else {
        return appId;
    }
}

我们可以在系统的框架中找到应用 uid 的计算方法。在多用户启用时，应用的 uid 等于 用户号 * 100000 + (应用 id % 100000) 。翻译一下，在一般情况下（指不溢出），对于用户 0 ，应用的 uid 等于应用 id 。对于别的用户，则应用 uid 等于 用户号 * 100000 + 应用 id。
形象的看一下，有一个应用在用户 0 的 uid 为 10137 ，那么它在用户 10 的 uid 就将会是 1010137 ，在用户 11 的 uid 将会是 1110137 。这，可以被看作一种有规律的“偏移”。

所以 SDCardFS 也需要继承这一逻辑，为不同用户目录下的“包名文件夹”提供与用户号相对应的 uid ，从而正确授予用户应用访问权限。
我们可以轻易的在 SDCardFS 的代码中找到与上方框架逻辑相对应的 uid 计算方式：

kernel/fs/sdcardfs/multiuser.h

#define AID_USER_OFFSET     100000 /* offset for uid ranges for each user */
......

typedef uid_t userid_t;
typedef uid_t appid_t;

static inline uid_t multiuser_get_uid(userid_t user_id, appid_t app_id)
{
    return (user_id * AID_USER_OFFSET) + (app_id % AID_USER_OFFSET);
}
......

在最终计算“包名文件夹”的 uid 时，上述方法会被调用，从而根据用户进行“偏移”：

kernel/fs/sdcardfs/derived_perm.c

case PERM_ANDROID_OBB:
case PERM_ANDROID_DATA:
case PERM_ANDROID_MEDIA:
    info->data->perm = PERM_ANDROID_PACKAGE;
    appid = get_appid(name->name);
    if (appid != 0 && !is_excluded(name->name, parent_data->userid))
        info->data->d_uid =
            multiuser_get_uid(parent_data->userid, appid);
    break;

于是，目标达成了，安装在不同用户下的应用即使使用着相同的 SDCardFS 挂载也能拿到正确的“包名文件夹” uid 。

别急，这只是处理了“包名文件夹”，但是针对拥有读/写权限应用，我们还有上面所提及的 EVERYBODY 组问题需要处理呢。
等等，还记得 EVERYBODY 组是干啥用的吗？可以向上翻一番 (●'◡'●) 。

那么，这个组是被不同用户中的应用中所共享的吗？
答案是否定的。
可以看到，在框架中，EVERYBODY 组对应的 gid 也会根据用户号进行“偏移”：

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

/**
 * Returns the gid shared between all apps with this userId.
 * @hide
 */
public static int getUserGid(@UserIdInt int userId) {
    return getUid(userId, Process.SHARED_USER_GID);
}

“偏移”采用的算法和上面的 uid 是一致的，再看看 SDCardFS 是如何实现这一点的：

kernel/fs/sdcardfs/sdcardfs.h

static inline int get_gid(struct vfsmount *mnt,
        struct super_block *sb,
        struct sdcardfs_inode_data *data)
{
    ......
        return multiuser_get_uid(data->userid, vfsopts->gid);
}

Easy，调用上面所提到的 multiuser_get_uid() ，把作为挂载参数传进来的 gid 根据用户号进行“偏移”即可。

小结

对 SDCardFS 的浅析到此就结束了，可以看到，它虽然是一个内核侧的驱动，但是它与 Android 系统之间的耦合可一点也不浅，甚至有不少 hardcode 的 dirty 操作来适应系统的需求。那么，当需求继续增加的时候会发生什么呢？那就接着往下看吧。

FUSE

FUSE 是 Filesystem in Userspace 的简称，是所谓“运行在用户空间的文件系统”。
自从 Android 11 起，它又重新回到了我们的视线。

引入：变态需求

Android 11 对 Android 10 引入的“分区存储”机制进行了改进，效果(1) 是这样的：

在没有存储权限的情况下，应用也可以访问“模拟存储”，但是只能列出目录结构，看不到也不能访问一般目录下的一般文件。
在没有存储权限的情况下，应用可以自由的在 “媒体目录”(2) 下创建文件夹和媒体文件。
在没有存储权限的情况下，应用只能看到和访问自己在“媒体目录”下创建的媒体文件(3)。
在拥有 READ_EXTERNAL_STORAGE 权限的情况下，应用可以看到 “媒体目录” 下别的应用创建的媒体文件。
即使拥有 READ_EXTERNAL_STORAGE 权限，应用也看不到除媒体文件外的任何文件。
WRITE_EXTERNAL_STORAGE 不再拥有任何效果。
文件管理类应用转而使用 MANAGE_EXTERNAL_STORAGE 权限，类似之前 WRITE_EXTERNAL_STORAGE 权限的效果。
非文件管理类应用，如有访问非媒体文件或非“媒体目录”的需求，必须采用 SAF 的实现（或者也可以让别的应用给你扔个 Uri ）。
无论是否拥有 READ_EXTERNAL_STORAGE 或 MANAGE_EXTERNAL_STORAGE 权限，应用都不再能够列出 Android/data/ 和 Android/obb/ 等目录，也无法访问其中非自己所属的文件夹(4)。
上述内容对一切文件操作方式均生效，无论是走 java 层或 native 层的文件 api ，还是优雅的使用 MediaStore 。

注释：

(1) 只针对 target api 达到要求的应用生效。
(2) 指 MediaStore api 使用的保存目录，比如 DCIM/、Pictures/、Download/ 等，具体参见文档。没错，“下载的文件”在这里姑且也被算作“媒体文件”了。
(3) 只能访问“本次安装”中自己所创建的内容。卸载重装后，自己之前创建的也访问不了ヾ(•ω•`)o 。
(4) 目前仍然可以通过 SAF ，使用构造的 Uri 来绕过这一限制。

总结一下：“媒体目录”里无需任何权限即可随便拉屎，还可以通过在“媒体目录”中创建特殊名字的文件夹跨应用追踪用户~~（低成本 IPC 方案）~~，甚至不需要请求任何权限。但没有权限只能看到自己创建的媒体可谓是非常的“沙箱”，非常的隐私。

再总结：拉屎成本降低，拉屎位置受限，吃屎十分困难（指偷窥其它应用创建的内容）。

那么问题来了，SDCardFS 还能通过继续改进来满足这些需求吗？想必这是十分困难的—— SDCardFS 的设计目标就是进行高效的纯内核态“转发”，但是对于上述需求，有太多依赖于用户态的东西了，几乎每一次访问都需要根据访问者身份和访问对象的具体情况来确定权限，而这些数据又无法直接被记录在下层文件系统中，频繁的内核态——用户态交互是避免不的了。

于是，FUSE 它回来了。

简介

在这里，先概述一下 FUSE 的工作方式。
FUSE 由两部分组成：内核侧的驱动和用户侧的“守护进程”。内核侧的 FUSE 驱动同样是一个“转发器”，但与 SDCardFS 不同的是，它不会将请求直接转发给“下层文件系统”(1) ，而是会将请求转发给位于用户空间的“守护进程”。守护进程在执行完相关操作后（比如鉴权、访问“下层文件系统”取得结果），再将结果返回给内核侧的驱动，最后内核侧的驱动将结果返回给发起请求的进程。

借用你谷在文档里放的图，一次基于 FUSE 的“模拟存储”访问就是这样一个歪七扭八的过程。

可以发现：

对下层文件系统的访问是由用户空间的“守护进程”完成的。
整个过程实际上进行了两次文件请求：第一次由“应用程序”发起，由内核侧的 FUSE 驱动处理；第二次由 FUSE “守护进程”发起，由“下层文件系统”处理。但别忘了，FUSE “守护进程”本身也是一个“应用程序”，所以千万注意不要让“守护进程”去访问自己负责的文件系统，否则就死循环了ヾ(•ω•`)o 。
两次请求，两次通过 VFS 层，来回进行用户态和内核态的切换，就意味着这玩意儿的性能不会好（呼应一下上面 SDCardFS 的简介）。

注释：

(1) 此处不考虑 FUSE Passthrough 。

来形象的代入一下一次 FUSE 请求：

应用访问 /sdcard/aaa。
请求在内核态兜了一圈被转发给了 FUSE “守护进程”。
“守护进程” 根据请求访问 /data/media/<用户号>/aaa。
“守护进程”把拿到的结果丢回内核态再兜一圈。
结果被交付给应用程序。

接下来，稍微再深入一点的了解这个过程吧，虽然也深不到哪里去。

从初始化开始

这一块内容主要聚焦于 FUSE 是如何被挂载并和“守护进程”取得联系的。这个过程牵扯到了不少系统模块，我会尝试以尽量简化的过程表述出来。
在这里，我们暂且忽略多用户，只关心主用户的情况。多用户会在后面再进行进一步分析。

一切的起点来自于 vold 的启动。 vold 即 volume daemon ，是位于 Android 框架和内核之间负责存储器相关事件传递和管理的底层服务。

vold 在启动时，会采用 hardcode 的方式创建“模拟存储卷”：

system/vold/VolumeManager.cpp

int VolumeManager::start() {
    ......
    auto vol = std::shared_ptr<android::vold::VolumeBase>(
            new android::vold::EmulatedVolume("/data/media", 0));
    vol->setMountUserId(0);
    vol->create();
    ......
}

而这一“创建事件”，会被向上传递到框架中，转交给 StorageManagerService ：

frameworks/base/services/core/java/com/android/server/StorageManagerService.java

@Override
public void onVolumeCreated(String volId, int type, String diskId, String partGuid,
        int userId) {
    synchronized (mLock) {
        final DiskInfo disk = mDisks.get(diskId);
        final VolumeInfo vol = new VolumeInfo(volId, type, disk, partGuid);
        vol.mountUserId = userId;
        mVolumes.put(volId, vol);
        onVolumeCreatedLocked(vol);
    }
}

StorageManagerService 在经过一些处理后，会重新调用 vold 来挂载这个“模拟存储卷”：
（这里传入的参数包含一个回调，在下面绕完一圈这个回调会被执行到，可以先留个心眼）

frameworks/base/services/core/java/com/android/server/StorageManagerService.java

private void mount(VolumeInfo vol) {
    ......
        mVold.mount(vol.id, vol.mountFlags, vol.mountUserId, new IVoldMountCallback.Stub() {
            ......
}

于是我们又回到了 vold 中，关键点来了，卷的挂载操作会调用到 MountUserFuse() 函数，而基于 FUSE 的“模拟存储”文件系统正是在这里被挂载的：

status_t MountUserFuse(userid_t user_id, const std::string& absolute_lower_path,
                       const std::string& relative_upper_path, android::base::unique_fd* fuse_fd) {
    std::string pre_fuse_path(StringPrintf("/mnt/user/%d", user_id));
    std::string fuse_path(
            StringPrintf("%s/%s", pre_fuse_path.c_str(), relative_upper_path.c_str()));

    ......

    // Open fuse fd.
    fuse_fd->reset(open("/dev/fuse", O_RDWR | O_CLOEXEC));
    if (fuse_fd->get() == -1) {
        PLOG(ERROR) << "Failed to open /dev/fuse";
        return -1;
    }

    // Note: leaving out default_permissions since we don't want kernel to do lower filesystem
    // permission checks before routing to FUSE daemon.
    const auto opts = StringPrintf(
        "fd=%i,"
        "rootmode=40000,"
        "allow_other,"
        "user_id=0,group_id=0,",
        fuse_fd->get());

    result = TEMP_FAILURE_RETRY(mount("/dev/fuse", fuse_path.c_str(), "fuse",
                                      MS_NOSUID | MS_NODEV | MS_NOEXEC | MS_NOATIME | MS_LAZYTIME,
                                      opts.c_str()));
    ......
}

我来翻译一下这个过程：首先，vold 对 /dev/fuse 设备被执行了一次 open() 操作，拿到了一个 fd （文件描述符）。接着，/dev/fuse 设备被挂载到了 /mnt/user/<用户号>/emulated ，挂载时这个 fd 会被作为参数传入。
注意到了吗？这个 fd 被存储在一个以指针形式传入的 unique_fd 中，接下来这个 fd 会被向上层层移交，在进程之间穿梭，最终被交到 FUSE “守护进程”的手中。
于是，FUSE “守护进程”的手里拿着这个 fd ，FUSE 被挂载时的参数里也装着这个 fd ，“守护进程”就这么和 FUSE 挂载点对应上了。
fd 在这里的作用就仿佛一个 token (1)，是关联 FUSE 挂载点和“守护进程”的关键纽带。

(1) 由于跨越了进程，fd 本身的数字值极有可能是不相同的，因此真正起到 token 效果的是这个 fd 在内核中对应的 struct file 。这里涉及到 Binder 跨进程传递 fd 的过程，不再继续展开了。

嗯，那就接着看看这个 fd 是如何被层层移交直到到达“守护进程”的吧。

fd 被从 vold 传递回框架层的 StorageManagerService 发生在上面的 FUSE 挂载函数被执行完之后，通过一个回调的方式进行：

system/vold/model/EmulatedVolume.cpp

status_t EmulatedVolume::doMount() {
    ......
        res = MountUserFuse(user_id, getInternalPath(), label, &fd);
        ......
            callback->onVolumeChecking(std::move(fd), getPath(), getInternalPath(), &is_ready);
            ......
}

于是我们又回到了这里，只不过上次走的是 mVold.mount() 路线，这次轮到执行里面的回调了：

private void mount(VolumeInfo vol) {
    ......
        mVold.mount(vol.id, vol.mountFlags, vol.mountUserId, new IVoldMountCallback.Stub() {
            @Override
            public boolean onVolumeChecking(FileDescriptor fd, String path,
                    String internalPath) {
                ......
                ParcelFileDescriptor pfd = new ParcelFileDescriptor(fd);
                try {
                    mStorageSessionController.onVolumeMount(pfd, vol);
                    ......
            }
        });
        ......
}

可以看到，通过一次 IPC ，fd 被从 vold 里传了过来，接下来被转交给了 StorageSessionController 。
StorageSessionController 则进一步创建并持有 StorageUserConnection ，并通过调用其 startSession() 方法将 fd 塞了进去：

frameworks/base/services/core/java/com/android/server/storage/StorageSessionController.java

public void onVolumeMount(ParcelFileDescriptor deviceFd, VolumeInfo vol)
        throws ExternalStorageServiceException {
    ......

    StorageUserConnection connection = null;
    ......
            Slog.i(TAG, "Creating connection for user: " + userId);
            connection = new StorageUserConnection(mContext, userId, this);
            ......
 
        ......
        connection.startSession(sessionId, deviceFd, vol.getPath().getPath(),
                vol.getInternalPath().getPath());
    ......
}

然后，fd 被继续转交给了 StorageUserConnection 中的一个内部类 ActiveConnection：

frameworks/base/services/core/java/com/android/server/storage/StorageUserConnection.java

    public void startSession(String sessionId, ParcelFileDescriptor pfd, String upperPath,
            String lowerPath) throws ExternalStorageServiceException {
        ......
        mActiveConnection.startSession(session, pfd);
    }

接下来又是一个关键点了：

frameworks/base/services/core/java/com/android/server/storage/StorageUserConnection.java
ActiveConnection 内部类

public void startSession(Session session, ParcelFileDescriptor fd)
        throws ExternalStorageServiceException {
    ......
        waitForAsyncVoid((service, callback) -> service.startSession(session.sessionId,
                FLAG_SESSION_TYPE_FUSE | FLAG_SESSION_ATTRIBUTE_INDEXABLE,
                        fd, session.upperPath, session.lowerPath, callback));
    ......
}

可以看出，我们给 waitForAsyncVoid 塞进了一个 lambda 表达式，很显然是一个回调，会在未来某时某刻再被执行。我压根就不关心它什么时候被执行，我只关心 service 是个啥？搞清楚 service 是什么非常重要，它可是 fd 将被交付给的对象。

那就接着深入看看：

frameworks/base/services/core/java/com/android/server/storage/StorageUserConnection.java
ActiveConnection 内部类

private void waitForAsyncVoid(AsyncStorageServiceCall asyncCall) throws Exception {
    ......

    waitForAsync(asyncCall, callback, opFuture, mOutstandingOps,
            DEFAULT_REMOTE_TIMEOUT_SECONDS);
}

private <T> T waitForAsync(AsyncStorageServiceCall asyncCall, RemoteCallback callback,
        CompletableFuture<T> opFuture, ArrayList<CompletableFuture<T>> outstandingOps,
        long timeoutSeconds) throws Exception {
    CompletableFuture<IExternalStorageService> serviceFuture = connectIfNeeded();

    ......
        return serviceFuture.thenCompose(service -> {
            try {
                asyncCall.run(service, callback);
            } catch (RemoteException e) {
                opFuture.completeExceptionally(e);
            }

            return opFuture;
        }).get(timeoutSeconds, TimeUnit.SECONDS);
    ......
}

看到这个 CompletableFuture 就已经明白了大半。
这个过程说白了是这样的：先去尝试连接到某个 ExternalStorageService ，在连接完成后通过 Binder 跨进程的调用其 startSession() 方法，同时把 fd 作为参数塞进去。由于“尝试连接”需要时间且不一定成功，因此这里构造了一个 waitForAsyncVoid() 框架来实现非阻塞的异步调用，看着很乱但目的还是很明确的。

所以，这里在寻找的某个 ExternalStorageService 是谁呢？

是 MediaProvider 里的 ExternalStorageServiceImpl ！
于是，第二次进程间通信完成了。第一次通信时 fd 被从 vold 传到了 system server 中，第二次通信则是将 fd 继续传递到了 MediaProvider 的一个服务里。
有一点看起来已经很清晰了，那便是：FUSE 的“守护进程”，或者说 FUSE 在用户侧的实现，是由 MediaProvider 模块负责的。

继续向下吧，终于，该轮到“守护进程”启动了！
fd 被进一步的塞给了 FuseDaemon：

packages/providers/MediaProvider/src/com/android/providers/media/fuse/ExternalStorageServiceImpl.java

@Override
public void onStartSession(@NonNull String sessionId, /* @SessionFlag */ int flag,
        @NonNull ParcelFileDescriptor deviceFd, @NonNull File upperFileSystemPath,
        @NonNull File lowerFileSystemPath) {
    ......
            FuseDaemon daemon = new FuseDaemon(mediaProvider, this, deviceFd, sessionId,
                    upperFileSystemPath.getPath());
            daemon.start();
            ......
}

需要注意的是，FuseDaemon 是一个线程，在这个线程上会执行 native 代码，并且~~直到 FUSE 崩溃才会返回~~永远不会返回。
这，正是“守护进程”的本体：

packages/providers/MediaProvider/src/com/android/providers/media/fuse/FuseDaemon.java

public final class FuseDaemon extends Thread {
    ......

    /** Starts a FUSE session. Does not return until the lower filesystem is unmounted. */
    @Override
    public void run() {
        ......
        native_start(ptr, mFuseDeviceFd, mPath); // Blocks
        ......
    }

    ......
}

进到 native 层看看：