GridFS本身不支持LDAP授权，完全依赖MongoDB实例级认证与角色授权；需在mongod配置LDAP并为用户授予对应数据库/集合权限，且权限须在admin库中显式绑定角色。
MongoDB 的 GridFS 本身不直接支持 LDAP 授权，它完全依赖于 MongoDB 实例级别的身份认证与数据库角色授权机制。也就是说：GridFS 没有独立的权限模型，所有访问控制都落在底层 mongod 的用户认证和 admin 数据库中定义的角色上。要让 GridFS 文件操作受 LDAP 约束，必须把 LDAP 集成到 MongoDB Server 层（不是 Ops Manager），并确保客户端使用 LDAP 用户凭据连接、且该用户被授予对应数据库/集合的操作权限。
LDAP 必须配置在 mongod 实例上，而非 GridFS 客户端或驱动层
很多人误以为 GridFS 驱动（如 PHP 的 mongodb/mongodb、Python 的 pymongo 或 Laravel 的 Flysystem GridFS 适配器）能“对接 LDAP”，其实不能。LDAP 认证由 mongod 进程在启动时通过 security.ldap 配置启用，所有连接请求（包括 GridFS 的读写）都先经过这层验证。
常见错误现象：
- 用
mongo --username uid=user,ou=people,dc=example,dc=com --authenticationMechanism PLAIN --authenticationDatabase '$external'能连上，但执行db.getSiblingDB('myapp').fs.files.find()报not authorized - LDAP 用户登录成功，却无法读取 GridFS 文件元数据（
files集合）或内容块（chunks集合）
原因很直接：LDAP 只管“你是谁”，不管“你能干啥”；权限仍需在 admin 数据库中显式绑定角色。例如：
use admin
db.createRole({
role: "gridfs_reader",
privileges: [
{ resource: { db: "myapp", collection: "fs.files" }, actions: ["find"] },
{ resource: { db: "myapp", collection: "fs.chunks" }, actions: ["find"] }
],
roles: []
})
db.grantRolesToRole("gridfs_reader", [{ role: "read", db: "myapp" }])
db.createUser({
user: "uid=user,ou=people,dc=example,dc=com",
roles: [{ role: "gridfs_reader", db: "admin" }],
authenticationRestrictions: [{ clientSource: ["192.168.10.0/24"] }]
})注意：authenticationRestrictions 是可选但强烈建议的加固项，防止 LDAP 凭据被跨网段滥用。
security.ldap.authz.queryTemplate 必须返回用户所属组名，且组名需与 db.createRole 中的 role 名一致
LDAP 授权（authz）阶段的核心是：MongoDB 根据 queryTemplate 向 LDAP 查询当前用户的所属群组，再将这些群组名当作角色名去 admin 数据库里找对应角色定义。所以：
- 如果 LDAP 返回
cn=gridfs-readers,ou=groups,dc=example,dc=com，那你在 MongoDB 中必须建一个叫gridfs-readers的 role（不是cn=gridfs-readers...全 DN） -
queryTemplate中的{USER}替换逻辑只认用户名部分（即uid=后面的值），不支持完整 DN 做变量；因此 LDAP 条目中memberUid字段应填user，而不是uid=user,ou=people,dc=example,dc=com - 如果你用的是
memberOf属性（Active Directory 常见），模板得写成：dc=example,dc=com?cn?sub?(memberOf=cn=gridfs-readers,ou=groups,dc=example,dc=com)—— 但注意这不是标准 OpenLDAP 用法，需确认服务器支持
典型失败配置示例：
security:
ldap:
servers: "ldap.example.com:389"
authz:
queryTemplate: "dc=example,dc=com?cn?sub?(objectClass=groupOfNames)(member=uid={USER},ou=people,dc=example,dc=com)"这个模板语法错误：LDAP filter 不支持嵌套括号写法，正确应为：(&(objectClass=groupOfNames)(member=uid={USER},ou=people,dc=example,dc=com))
Laravel / Flysystem GridFS 适配器不自动传递 LDAP 凭据，需手动构造连接字符串
像 league/flysystem-gridfs 这类适配器默认走 PHP 的 MongoDB\Driver\Manager，它不解析 mongodb:// URI 中的 $external 数据库或 PLAIN 机制字段。你必须显式传入认证参数：
错误写法（URI 中带 $external 但驱动忽略）：
'mongodb://uid=user,ou=people,dc=example,dc=com:pass@192.168.10.5:27017/?authSource=$external&authMechanism=PLAIN'
正确做法（在 Laravel 的 config/filesystems.php 中）：
'gridfs' => [
'driver' => 'gridfs',
'connection' => 'mongodb',
'bucket' => 'fs',
'options' => [
'authMechanism' => 'PLAIN',
'authSource' => '$external',
'username' => 'uid=user,ou=people,dc=example,dc=com',
'password' => 'xxx',
],
],同时确保 config/database.php 中的 mongodb 连接也启用相同认证参数，否则 Flysystem 初始化 Bucket 时会因未认证而失败。
GridFS 文件元数据（files 集合）才是权限控制的关键落点
真正需要加权限校验的不是 chunks 集合（它只是二进制块，没业务语义），而是 files 集合里的文档 —— 因为它包含 filename、metadata、uploadDate 等可被查询和过滤的字段。你可以在 metadata 里存自定义权限字段，比如：
{
"_id": ObjectId("..."),
"filename": "report.pdf",
"metadata": {
"owner_id": "user123",
"allowed_roles": ["editor", "manager"],
"is_public": false
}
}然后配合 find 查询做运行时检查（例如 Laravel 中用 GridFSBucket::find() 加 $filter）：
$bucket->find([ 'filename' => 'report.pdf', 'metadata.owner_id' => 'user123', 'metadata.allowed_roles' => ['$in' => ['editor']] ])
这种方案不依赖 LDAP，但能和 LDAP 用户角色联动：应用层从 LDAP 获取当前用户角色列表，再拼进查询条件。这是目前最灵活、也最容易审计的细粒度控制方式。
容易被忽略的一点：MongoDB 的 read 角色默认允许对 files 和 chunks 集合执行 find，但它不会自动过滤文档内容。也就是说，只要用户有 read 权限，就能看到所有文件的元数据 —— 所以业务层必须自己做 metadata 字段级过滤，不能只靠数据库角色。
