MongoDB角色中无地理空间权限项，因其所有地理空间查询（如$near、$geoWithin）均归类为find行为，只要具备find权限且集合建有2dsphere索引即可执行；权限系统未单独抽象geo操作，仅通过资源+行为模型统一管控。
MongoDB 本身不支持在 Role 中按地理空间操作（如 $geoNear、$geoWithin）粒度定义权限。 它的空间查询能力完全复用标准 CRUD 权限模型，没有独立的「地理空间权限」字段或内置角色可启用/禁用某类 geo 操作。
为什么 Role 里找不到 geo 相关权限项
MongoDB 的权限系统基于「资源 + 行为」二维模型，而所有地理空间查询（$near、$geoIntersects、$geoWithin 等）都被归类为 find 行为的一部分。只要用户对集合有 find 权限，且该集合已建 2dsphere 索引，就能执行任意空间查询——无论是否带坐标过滤、是否跨区域。
常见误解来源：
- 误以为 read 角色只允许普通读取，实际它隐含完整 find 能力
- 期待像 dbAdmin 那样有 geoRead 这类角色，但官方从未提供
真正起作用的访问控制层只有三个
想限制地理数据被查，只能从以下层面切入：
- 网络层：用
--bind_ip或mongod.conf中的net.bindIp限定可连接的客户端 IP 段，比如只放行内网服务地址 - 认证层：启用
security.authorization: enabled，并为不同应用分配最小权限用户（例如仅授予read角色到特定数据库+集合） - 应用层：在业务代码中拦截、校验查询条件——比如拒绝
coordinates字段出现在$where或聚合管道中的非白名单字段
注意：2dsphere 索引本身不参与权限判定；即使用户无索引管理权限，只要能 find，仍可触发空间查询（只是性能极差）。
容易被忽略的危险点：GeoJSON 数据本身可被普通 find 泄露
很多团队只关注「能不能做空间查询」，却忘了 GeoJSON 坐标是明文存储在文档里的。只要用户有 find 权限，就能直接 db.places.find({}) 拿到全部经纬度：
db.places.find({name: "Beijing Tower"}, {location: 1})
返回结果中 location.coordinates 就是 [116.4, 39.9] —— 完全绕过任何空间索引或查询逻辑。所以：
- 敏感位置数据（如用户实时定位）必须加密存储，不能依赖权限隐藏
- 不要把
read角色直接给前端或第三方 SDK；应通过后端 API 做字段裁剪和范围过滤 - 审计日志里要监控高频
find请求，尤其是带空条件或大范围投影的
