GridFS本身不支持文件级权限控制，必须应用层校验与MongoDB RBAC双层协同：RBAC需禁用secure_files.chunks所有权限，仅对secure_files.files配置带privilegeDocument的行级过滤，应用层上传时强制写入metadata.access_control字段并下载前校验。
GridFS 本身不支持文件级权限控制，必须靠应用层校验 + MongoDB RBAC 双层兜底——只配 RBAC 挡不住绕过业务逻辑的直连攻击，只做应用层校验又防不住数据库层面的批量扫描。
为什么直接给 secure_files.chunks 授权限是错的
很多人误以为给 chunks 集合加 read 权限就能控制文件读取，其实完全相反：chunks 是纯二进制块存储，MongoDB 不允许在该集合上建索引、加查询条件，也无法嵌入 metadata 字段。一旦开放该集合权限，攻击者可用 db.getCollection('secure_files.chunks').find() 全量拉取所有块，再拼出任意文件。
- RBAC 必须禁止对
secure_files.chunks的任何操作权限（find、insert、delete） - 所有权限判断逻辑必须收敛到
secure_files.files集合，且只允许通过metadata.access_control字段过滤 - 应用层调用
GridFSBucket.openDownloadStream()前，必须先查files文档并校验权限，不能跳过这步直接开流
db.createRole() 中如何定义带行级过滤的 files 集合权限
MongoDB 4.4+ 支持在 privileges 里用 privilegeDocument 做服务器端行级过滤，这是防止绕过应用层的关键一环。错误写法是只授权 { resource: { db: "mydb", collection: "secure_files.files" }, actions: ["find"] }，这样用户能扫出全部文件 ID。
- 正确做法是显式声明
privilegeDocument，例如只允许查当前用户有权限的文件：{ resource: { db: "mydb", collection: "secure_files.files" }, actions: ["find"], privilegeDocument: { "metadata.access_control.user_ids": { "$in": ["$$USER_ID"] } } } - 注意
$$USER_ID是 MongoDB 内置变量，需配合authenticationRestrictions或应用层传入的 session context 使用；若用角色继承方式，确保基础角色已绑定用户标识字段 - 对角色组权限（如
roles: ["editor"]），要用"metadata.access_control.roles": { "$in": ["$$ROLES"] }，不能写成"metadata.access_control.roles": "editor"—— 后者无法命中数组索引
应用层 find() 查询必须匹配索引结构
即使 RBAC 做了行级过滤，应用层自己查 files 集合时如果查询写法和索引不匹配，仍会触发全集合扫描。常见坑是以为建了复合索引就万事大吉，结果发现 find({ 'metadata.access_control.roles': 'editor' }) 慢得离谱。
- 必须为嵌套数组字段单独建多键索引：
db.getCollection('secure_files.files').createIndex({ 'metadata.access_control.user_ids': 1 })和{ 'metadata.access_control.roles': 1 } - 查询时用
$in而非$eq：用{ 'metadata.access_control.user_ids': { $in: ['u123'] } }才能走索引，{ 'metadata.access_control.user_ids': 'u123' }在数组字段上可能失效 - 避免在
metadata里存owner_id这类单值字段——它无法表达“多人可读”，后续也无法扩展为数组索引
上传时漏写 metadata.access_control 导致权限失效
很多团队把权限逻辑全塞在下载流程里，上传时却用裸 GridFSBucket.openUploadStream()，没往 files 文档的 metadata 里写任何权限字段。结果是 RBAC 的 privilegeDocument 根本没东西可匹配，等于形同虚设。
- Laravel 示例中必须显式传入：
$disk->put('a.pdf', $content, ['metadata' => ['access_control' => ['user_ids' => ['u123'], 'roles' => ['viewer']]]]) - Node.js 中用
bucket.uploadFromStream()时，options.metadata必须包含access_control对象，不能只传空对象或忽略该参数 - 禁止在
metadata存敏感信息（如 token、密码），RBAC 不加密字段内容，files集合本身是可被管理员查看的
最易被忽略的一点：超级管理员账户（如 DBAAdmin）绝不能混入应用连接池。一旦泄露，RBAC 和应用层校验全部失效——它能绕过所有 privilegeDocument 直接查 files 和 chunks。这个账号必须独立管理、严格审计、仅限人工运维使用。
