登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

getfacl 中 effective 权限为什么小于用户条目的权限

来源:17golang原创

时间:2026-11-10 12:30:00 494浏览 收藏

看到 getfacl 输出里的 user:deploy:rwx #effective:r-x,不要把它理解成“用户条目没有生效”。真正的含义是:命名用户条目申请了 rwx,但 ACL 的 mask::r-x 把可写权限裁掉了,所以这次访问最多得到 r-x。effective 是最终上限,不是另一条独立授权。

要点速览
  • 命名用户和命名组的有效权限,等于自身条目与 mask 的交集。
  • user:: 文件所有者和 other:: 其他用户不受 ACL mask 限制。
  • 排查时同时看 mask::、group::、用户所属组,以及目录的 x 搜索权限。

先把 getfacl 的几行权限分开看

扩展 ACL 常见的核心行可以压缩成下面这张表:

条目作用是否受 mask 限制
user::文件所有者否
user:deploy:指定用户是
group::文件所属组是
group:ops:指定组是
mask::命名用户、所有组条目的共同上限它本身就是上限
other::不匹配前面条目的其他用户否

例如:

# 读取文件的访问 ACL;这里只观察权限,不修改文件
getfacl -p /srv/app/config.yaml

# 可能看到的关键行:命名用户申请 rwx,但 mask 只有 r-x
user:deploy:rwx                 #effective:r-x
group::r--
mask::r-x

这里的 rwx 是条目本身写入的权限,r-x 才是受 mask 限制后的有效权限。官方 getfacl 手册也把 mask 描述为限制所有组和命名用户的 effective rights;owner 与 other 不在这个范围内。

Linux getfacl 命名用户权限条目与 ACL mask 共同决定 effective 权限的静态结构说明图
图1:权限条目与 mask 的边界说明图;这是原创静态说明图,不是终端截图或运行证据。

effective 权限就是条目与 mask 的交集

可以把每个权限位看成一个开关。命名用户条目是 rwx,mask 是 r-x,按位相与后只剩 r-x:

# 下面是手工核对思路,不会修改 ACL
entry="rwx"                         # 命名用户条目的申请权限
mask="r-x"                          # ACL mask 给出的共同上限
echo "effective = entry ∩ mask"     # 结果是 r-x,w 位被 mask 拦截

因此,单独把 user:deploy: 改成 rwx,并不能恢复写权限;必须先确认 mask:: 是否包含 w。同一规则也作用于 group:: 和命名组条目。文件所有者匹配 user:: 时走自己的条目,其他用户匹配 other:: 时也不经过 mask。

这也是为什么 ls -l 的“组权限”容易让人困惑:当文件带扩展 ACL 时,它对应的是 ACL group class 的 mask,而不一定等于某个具体 group:: 条目的原始权限。

为什么 mask 会悄悄变小

最常见的原因不是 getfacl 读错,而是后续修改改变了 ACL 的组类权限。比如 setfacl 默认会重新计算 mask,除非命令显式给出了 mask;而 chmod 的组权限位也可能映射到 ACL 的 mask。

# 给 deploy 写入 rwx,并明确把共同上限保留为 rwx
# -m 表示修改 ACL;逗号分隔多个条目
setfacl -m u:deploy:rwx,m::rwx /srv/app/config.yaml

# 只收紧共同上限,保留命名用户原始条目,便于以后恢复
setfacl -m m::r-x /srv/app/config.yaml

# 再查看完整访问 ACL,确认 mask 与 effective 注释
getfacl -p /srv/app/config.yaml

生产环境不要只执行第一行就结束。把 setfacl 的参数、脚本默认值和后续 chmod 一起查出来,否则修复后的 mask::rwx 可能又被部署脚本收紧。

Linux ACL 中 setfacl、chmod、mask、命名用户与文件访问结果之间关系的静态结构图
图2:修改来源与生效边界的关系图;图中只表达 ACL 实体关系,不代表真实执行流程。

用访问者身份做一次完整排查

确认权限时至少回答三个问题:访问者是否命中命名用户条目?如果没有,是否通过某个组条目命中?路径上的每一级目录是否都有搜索权限?可以按下面的顺序收集证据:

如果输出显示 user:deploy:rwx #effective:r-x,同时 id deploy 确认身份正确,那么下一步先看 mask::;不要直接重复增加用户条目。若文件权限看似足够但仍返回“Permission denied”,再沿父目录检查搜索权限,以及挂载点是否真的支持 POSIX ACL。

目录还有一个容易混淆的边界:default: ACL 只影响新建对象的继承模板,不能替代当前目录本身的 access ACL。排查现有文件时先看没有 default: 前缀的访问 ACL。

常见问题

把 mask 改成 rwx 后,为什么仍然不能写?

先确认命名用户条目本身含有 w,再检查父目录的 x 和 w,以及文件系统挂载和只读属性。mask 只是上限,不会自动增加条目权限。

group::r-- 和 mask::r-x 同时出现时,实际组权限是什么?

对文件所属组来说,具体 group::r-- 仍只有读;mask 允许的执行位不会凭空添加到条目。

能否只隐藏 effective 注释?

可以用 getfacl -E 不显示 effective 注释,但这只改变输出,不改变 ACL。排障时建议保留默认注释,或用 getfacl -e 显式显示所有条目的 effective 权限。

记住一个简单判断:条目决定“想给什么”,mask 决定“组类最多能给什么”,两者交集才是命名用户或组真正拿到的权限。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>