如何在GridFS中对特定业务线的数据设置不同的访问控制

必须在gridfs元数据中显式写入业务线标识（如”biz_line”:”payment”），并基于该字段建索引、配置带Filter的mongodb角色权限，应用层须先校验文件存在性再下载，严禁绕过权限检查直接操作fs.chunks。

GridFS 文件元数据里存业务线标识是前提

不往 metadata 字段写业务线信息，后续所有权限控制都无从谈起。MongoDB 本身不识别“业务线”概念，它只认你塞进去的字段值。

实操建议：

• 上传文件时必须显式设置 metadata，比如：{ "biz_line": "payment", "env": "prod" }
• 避免用文件名或 _id 推断业务线——不可靠、难审计、查询慢
• 统一约定键名（如固定用 biz_line），别一会儿 business 一会儿 line

MongoDB 角色定义要基于 find 查询过滤器

GridFS 实际是两个集合（fs.files 和 fs.chunks），权限得落在 fs.files 上，因为它是元数据入口；fs.chunks 不做细粒度控制——查不到文件就拿不到 chunk ID，自然读不了内容。

常见错误现象：角色只给了 find 权限但没限制条件，结果用户能列全库所有 GridFS 文件。

实操建议：

• 用 db.createRole() 定义角色时，在 privileges 里指定 Resource: { "Collection": "fs.files", "db": "your_db" }
• actions 至少包含 "find"，不能只给 "read"（太宽泛）
• 关键一步：在 resource 下加 "filter": { "metadata.biz_line": "payment" }，这才是隔离核心

应用层必须用 find + openDownloadStream 组合查文件

很多开发者直接调 bucket.find({}) 拿游标，再逐个 openDownloadStream——这会绕过 MongoDB 层的 filter 权限检查，因为 bucket.find 是驱动封装逻辑，不走原生权限引擎。

使用场景：用户请求下载 ID 为 abc123 的文件，且已知属于 logistics 线。

实操建议：

• 先用带权限的角色连接 DB，执行 db.fs.files.find({ "_id": ObjectId("abc123"), "metadata.biz_line": "logistics" })
• 确认返回非空再调 bucket.openDownloadStream(new ObjectId("abc123"))
• 别省掉第一步校验——否则攻击者可伪造 ID 直接读 chunk

注意 fs.chunks 的隐式依赖和索引影响

即使你在 fs.files 上做了完美过滤，如果应用代码没校验文件存在性就直接拼 fs.chunks 的 files_id 去查，可能触发未授权访问。MongoDB 不会对 chunks 集合自动关联 files 的权限规则。

性能影响：每个业务线数据量差异大时，fs.files 上的 metadata.biz_line 字段必须建索引，否则 filter 权限对应的查询会全表扫。

实操建议：

• 在 fs.files 上建支撑索引：db.fs.files.createIndex({ "metadata.biz_line": 1 })
• 禁止应用层直接操作 fs.chunks——所有读写必须经由 GridFSBucket API
• 测试时用低权限账号连，故意传错 biz_line 值，看是否真被拒而不是静默返回空

真正卡住人的地方往往不是语法，而是 metadata 写没写对、索引建没建、以及有没有在应用层多补那一行存在性校验。