管理Agent访问控制列表（ACL）-云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

多个 Agent 共享同一棵目录树的应用场景，通常要求每个 Agent 只能访问已授权给它的文件和目录。传统 POSIX 权限只有owner / group / other三级，无法表达“用户 A 可读、用户 B 不可读、用户 C 可写”这类按uid/gid 独立设置的细粒度授权。PolarDB Agent LakeBase 支持 POSIX 访问控制列表（ACL，Access Control List），可为文件或目录设置用户或用户组级别的访问权限。这一机制突破了传统三级权限的限制，支持多 Agent 共享目录树时按 uid / gid 独立授权。

说明

该功能目前处于邀测阶段，使用此功能之前需要先开启实例的 ACL 功能。如需使用，请通过钉钉搜索群号 34560007316 加入技术交流群咨询。

功能特性

PolarDB Agent LakeBase 通过 POSIX ACL 的用户 / 用户组 ACE（Access Control Entry）解决以上问题：

使用 root 用户针对文件或者目录独立设置某个 Agent 对应uid/gid的读、写、执行权限，Agent 使用非 root 用户访问文件 / 目录，Agent 之间共享目录而互不越权。
使用标准 setfacl / getfacl 命令，与 Linux 生态无缝衔接，无需学习私有接口。
默认ACL自动继承。为目录设置默认ACL后，该目录下新建的文件和子目录自动继承授权规则，无需逐个补设。

适用范围

已创建PolarDB Agent LakeBase实例。
PolarDB Agent LakeBase实例已启用ACL功能。

配置 FC 沙箱身份（userId / groupId）

以阿里云函数计算（Function Compute，简称FC）沙箱挂载PolarDB Agent LakeBase的场景为例：FC创建沙箱时通过 PolarFsConfig / PolarFsMountConfig 参数将 PolarDB Agent LakeBase 挂载到沙箱，并指定沙箱进程运行时的 userId 与 groupId，后续 setfacl 以该 userId / groupId 作为授权的 uid / gid。FC 沙箱参数结构详见PolarFsConfig。

重要

指定 root 用户（userId 和 groupId 均为 0）来管理 ACL，Agent 运行时指定非 root 用户。root 用户会绕过权限检查。

设置 ACL

使用 setfacl 为文件或目录设置用户 / 用户组权限。

示例1：为单个文件授权，保留属主的读写权限，拒绝用户组和其他用户访问，并单独授予 uid=1001 的用户读取权限：
```
setfacl -m u::rw-,g::---,o::---,m::rwx,u:1001:r-- <mountDir>/u1001_file.txt
```
示例2：为目录递归授权，并为该目录下新建的文件设置默认 ACL：
```
setfacl -R -m u::rwX,g::---,o::---,u:1001:r-X \
    -m d:u::rwx,d:g::---,d:o::---,d:u:1001:r-x <mountDir>/u1001_dir
```
setfacl 的参数说明详见 man setfacl。授权完成后，可通过 getfacl 查询文件或目录的 ACL 确认授权结果，详见查询 ACL。

查询 ACL

使用 getfacl 查询文件或目录的 ACL。

getfacl <mountDir>/u1001_file.txt

参数说明详见 man getfacl。

删除 ACL

删除文件或目录上的指定 ACL 条目，或清空全部扩展 ACL。

# 删除指定用户的 ACL 条目
setfacl -x u:1001 <mountDir>/u1001_file.txt

# 清空文件上的全部扩展 ACL
setfacl -b <mountDir>/u1001_file.txt

典型应用场景

多 Agent 共享目录树，按 Agent 授权

多个 Agent 共享同一棵目录树，管理员先通过 root 用户使用 setfacl 为每个 Agent（uid）授权，Agent 用各自的 uid 挂载后即可访问授权范围内的内容，越权访问返回 Permission denied。

示例：目录 u12_dir 与文件 u12_file.txt 供 uid 1001、1002 读取，目录 u23_dir 与文件 u23_file.txt 供 uid 1002、1003 读取，管理员设置步骤如下：

# u12_xxx：1001/1002 可读
setfacl -R -m u:1001:r-X,u:1002:r-X -m d:u:1001:r-x,d:u:1002:r-x <mountDir>/u12_dir
setfacl    -m u:1001:r--,u:1002:r-- <mountDir>/u12_file.txt

# u23_xxx：1002/1003 可读
setfacl -R -m u:1002:r-X,u:1003:r-X -m d:u:1002:r-x,d:u:1003:r-x <mountDir>/u23_dir
setfacl    -m u:1002:r--,u:1003:r-- <mountDir>/u23_file.txt

ACL 生效范围与使用限制

ACL 条目写入 PolarDB Agent LakeBase 元数据库，对所有挂载的客户端全局生效；权限变更的可见实时性取决于客户端缓存配置。
对已设置扩展 ACL 的文件执行 chmod 时，chmod 的属组权限位作用于 ACL 的 mask 条目，可能影响用户 / 用户组的有效权限，建议统一使用 setfacl 管理权限。
单个 inode 的 uid / gid ACE 上限为 507 条，由 Linux 内核 FUSE 层限制决定，与文件系统实现无关。
目录同时具备 access ACL 与 default ACL，两者各自独立计数、互不占用配额。
当 ACE 数量接近上限时，建议改用 gid ACE 聚合授权，让一条 gid ACE 覆盖该组下所有成员，避开上限并降低 ACL 维护成本。
默认 ACL（default ACL）仅对该目录下新建的文件和子目录自动继承，对已存在的条目不生效。
文件重命名（rename）后 inode 保持不变，已设置的 ACL 随文件保留。

常见问题

为什么已授权的用户访问时仍返回 Permission denied？

如果该用户未被授权，访问被拒绝属于预期行为。如果用户已授权但仍返回 Permission denied，可能由以下原因导致：

权限变更尚未在当前客户端生效。ACL 条目对所有挂载的客户端全局生效，但权限变更的可见实时性取决于客户端缓存配置。
对已设置扩展 ACL 的文件执行过 chmod。此时 chmod 的属组权限位作用于 ACL 的 mask 条目，可能影响用户 / 用户组的有效权限。
访问的条目在默认 ACL 设置之前已存在。默认 ACL 仅对设置后新建的文件和子目录自动继承，对已存在的条目不生效。