一开始,我对文件具有以下权限:
# file: jar
# owner: my_user
# group: my_user
user::rw-
group::rw-
other::r--
运行此命令后:
setfacl -m u:my_user:--- jar
并获得此权限:
# file: foobar
# owner: my_user
# group: my_user
user::rw-
user:my_user:---
group::rw-
mask::rw-
other::r--
我预计my_user
没有权限读取(例如)此文件,但它有..
答案1
尝试下一个命令:
setfacl -m u::--- jar
有了这个突击队,你就可以向业主提出申请。
答案2
你为什么会这样期望?
来自man setfacl
手册页:
setfacl 实用程序可识别以下 ACL 条目格式(为了清楚起见,插入了空格):
[d[efault]:] [u[ser]:]uid [:perms]
指定用户的权限。如果 uid 为空,则文件所有者的权限。
[d[efault]:] g[roup]:gid [:perms]
指定组的权限。如果 gid 为空,则拥有组的权限。
[d[efault]:] m[ask][:] [:perms]
有效权利掩蔽
[d[efault]:] o[ther][:] [:perms]
他人的许可。
ACL 与传统的 Unix 访问控制(所有者、组以及所有者、组和其他人的权限掩码)是分开的。
虽然我们想不出任何理由说明为什么您需要与传统访问控制具有相同用户或组的 ACL,但 Unix 哲学并不认为应该因此禁止它。setfacl
很高兴允许你这样做;吻很好。
如果您不喜欢这种行为,并且希望实用程序“自动检测”这种情况,您可以编写自己的包装器setfacl
。在 shell 脚本中,您可以使用stat -c %U FILE
来获取所有者的名称以及stat -c %G FILE
文件或目录的组的名称FILE
。根据我的经验,在具有复杂的用户和组集的组织中,此类包装器(不仅适用于setfacl
文件所有权管理,而且适用于所有文件所有权管理)无处不在。